Towards a Development Environment for Secure CyberPhysical … · 2015-07-09 · Politecnico di...

Politecnico di MilanoFacoltà di Ingegneria dell’Informazione

Corso di Laurea Specialistica in Ingegneria InformaticaDipartimento di Elettronica, Informazione e Bioingegneria

Tesi di Laurea

Towards a Development Environment for SecureCyberPhysical Spaces

Relatore: Prof. Carlo GHEZZICorrelatore: Prof. Bashar NUSEIBEH

Laureando: Edoardo PASIMatr. n. 805753

Anno Accademico 2014-2015

Quaand la roesa se spalanca la desmentega i so spenn

Davide Van De Sfroos

Ringraziamenti

Desidero ringraziare il mio relatore Carlo Ghezzi che mi ha trasmesso la passione per

l’ingegneria del software, intesa nel suo senso più ampio cioè come ricerca della perfezione,

del modo migliore di fare una certa cosa. Forse ancora più importante è un esempio di

come si possa raggiungere risultati importanti e mantenere un atteggiamento cortese e

disponibile.

Un importante ringraziamento va alla mia famiglia che mi ha sempre supportato (sop-

portato) e che ha reso possibile il mio percorso fino a qua: dai primi istanti di vita,

durante tutto il mio i percorso scolastico e universitario, fino alla redazione di questa

tesi (che sono dispensati dal leggere, a eccezione di questa pagina). Ogni membro della

mia frastagliata famiglia in qualche modo ha contribuito a formare la persona che sono

e che ero sei mesi fa quando è iniziato questo lavoro, e quindi anche a loro va il merito

di questa tesi che oggi vede la luce.

Un grazie particolare va ai miei amici che da sempre sono stati la naturale estensione

della mia famiglia: in ordine cronologico, per quanto possibile, ricorderei Edo, il mio

omonimo: compagno di mille avventure e sventure, che, come la mia famiglia naturale,

mi sopporta da molti anni e ancora non dà cenni di cedimento; ricordo Ale, ora a servizio

del PIME, un tempo infaticabile atleta, ma più importante amico fidato ed esempio di

valori pressoché introvabili come l’amicizia ad ogni costo verso tutto e tutti. Di grande

importanza, e ormai alla prova da tempo, sono anche Andrea, dal quale ho cercato di

imitare l’ottimismo che rasenta la sfacciataggine (atteggiamento da non sottovalutare

durante la ricerca), e Alice: forse fra i miei amici la persona che più bonariamente i miei

difetti. Non posso proprio dedicare tutto lo spazio che meriterebbero agli altri amici di

Rogoredo cito soltanto: Samuel (che ringrazio per gli enormi sforzi atti a capire cosa fosse

o non fosse una Macchina di Turing), Sara, Alessandro, Arianna, Carolina, Riccardo (di

cui però ricordo almeno i baffi proverbiali).

Non si possono proprio dimenticare gli amici del PIME, sorprendenti e speciali, meritereb-

bero una piccola tesi o una piccola enciclopedia (ciascuno proprio intendo); a causa loro

ho sacrificato molto tempo, spesso sottratto agli esami (una volta persino alla tesi, devo

iii

confessare), ma di cui non rimpiango neanche un minuto perché la loro compagnia mi ha

sempre ricaricato e consentito di recuperare persino quel tempo apparentemente perso.

Non volendo relegare nessuno di loro ad amico di serie B evito di ricordare nomi par-

ticolari, a eccezione di Rita che ha minacciato di togliermi dagli amici di Facebook in

caso contrario e a Lollo che devo necessariamente citare in merito a profonde discussioni

sull’ingegneria del software. Un abbraccio a tutti gli amici-pime che non ho citato ma

che prometto di ringraziare di persona.

Il viaggio fra le persone a cui sono grato continua con gli amici del Politecnico. Primo fra

tutti Claudio, che è stato, ed è tuttora, un prezioso esempio di come si possa coltivare la

passione per l’informatica senza diventare dei sociopatici e trascurare le cose belle della

vita. Con Claudio ho condiviso frustrazioni e fallimenti che pian piano si sono trasformati

in soddisfazioni e successi (non sempre, ma diciamo spesso), mal di testa incurabili

di fronte a lavagne fitte di informazioni incomprensibili, che provavamo a decifrare (di

nuovo, non sempre, ma spesso, con successo). Non posso fare a meno di ricordare e

persino ringraziare Walter, cocciuto avversario di mille discussioni, ma in fondo amico

leale. Devo almeno citare Dave che, come un relatore in miniatura, mi ha insegnato la

passione per il buon codice e per Skyrim. Infine un grazie ad Ema (secure-Ema), a Rufy,

e a Teto-Tomma.

Last, but not list (off course!) a special thank to the LERO team. I want to start with

Bashar that made this work possible, being my co-supervisor with Carlo, hosting me

in his research group and making me feel like home and in a confortable environment.

As Carlo, also Bashar is an example of a person that had reached some important goals

without lousing politeness nor the smile. A special thanks to Liliana, for different reasons,

personal and technical; as Bashar and the rest of LERO team, she made me feel welcome

since the very first day I arrived in Limerick. Moreover, Liliana helped me quite a lot

during the implementation of the tool we realized, her technical advices were precious

and I am really grateful. A great thank also to the rest of the LERO team I spent time

with, namely: Sorren, Fayola, Marco.

Extended Abstract (in Italian)

Introduzione

Questo lavoro di tesi nasce all’interno di un progetto nell’ambito della sicurezza che coin-

volge il Politecnico di Milano, in particolare il Dipartimento di Elettronica Informazione

e Bioingegneria, e la Limerick University, in particolare il Centro di Ricerca Irlandese per

l’Ingegneria del Software (LERO). Il gruppo di ricerca con cui ho avuto l’opportunità di

collaborare si è occupato della sfida di ingegnerizzare sistemi critici dal punto di vista

della sicurezza in grado di adattarsi alle modifiche che avvengono al loro interno, detti

sistemi di sicurezza adattativi. Di grande importanza in questi sistemi è la nozione di

topologia dell’edificio, della descrizione degli ambienti che lo compongono, delle relazioni

di prossimità e raggiungibilità fra questi, delle risorse e degli agenti che si trovano in

questi spazi. Si parla in questo caso di “Topology Aware Adaptive Systems” cioè sistemi

che sono consci della loro topologia e in grado di adattarsi per soddisfare determinati

requisiti di sicurezza.

In alcuni ambienti il problema della sicurezza è intrinsecamente critico, basti pensare ad

edifici come: aeroporti, ospedali, banche, edifici governativi etc. La domanda da cui è

scaturito questo lavoro di tesi è stata: “Esistono tecniche, in industria o in letteratura

scientifica, per affrontare in modo formale e sistematico il problema della sicurezza a

partire dalla prime fasi del progetto di un edificio?”. Per rispondere a questa domanda

abbiamo effettuato sia un’analisi della letteratura scientifica, per cercare di capire come,

chi progetta edifici, si pone verso il problema della sicurezza, sia un’analisi di applicazioni

commerciali a supporto della sicurezza in ambienti fisici.

L’obiettivo che ci siamo proposti e da cui è cominciato il lavoro che poi ha portato alla

realizzazione di questa tesi, è stato quello di realizzare un software che permettesse, da

un lato di iniziare il progetto di un edificio e controllare fin da subito il soddisfacimento

di alcuni requisiti di sicurezza, dall’altro di consentire ad amministratori di sicurezza, di

controllare lo stato e la posizione di risorse e agenti in un edificio e di scoprire e prevenire

eventuali violazioni della sicurezza a fronte di particolari requisiti.

v

La nostra ricerca è iniziata indagando quale fosse lo state dell’arte per quanto riguarda

la rappresentazione di edifici, ciò ci ha portati a BIM (Building Information Modelling),

una tecnologia molto utilizzata in architettura e in ingegneria delle costruzioni. BIM

consente di creare modelli in cui la semantica di ogni parte dell’edificio è ben formalizzata.

Questa ricchezza semantica è stata sfruttata in diversi lavori in ambito accademico che

hanno dimostrato come sia possibile sfruttare modelli BIM per trarre vantaggio, dal

punto di vista della sicurezza, nella progettazione di edifici e nel loro monitoraggio.

Una fase successiva della nostra ricerca è stata l’analisi di rassegna di software esistente

che supportasse la gestione della sicurezza fisica; esistono applicazioni commerciali sia

per valutare il grado di difesa offerto da un edificio che per monitorare la situazione al

suo interno: permettono cioè di raccogliere, in un’unica interfaccia, dati provenienti da

strumenti diversi e di fornire una sorta di cruscotto utile alla sorveglianza.

Questa ricerca ci ha portato a concludere che un software come quello che ci eravamo posti

di realizzare non costituisce un’idea eccessivamente particolare, ma allo stesso tempo non

esiste nulla che soddisfi pienamente gli obiettivi da noi individuati. Arrivati a questa

conclusione abbiamo iniziato la progettazione del software che abbiamo chiamato Ma-

raudersWare. In questo lavoro di tesi presentiamo il tool che abbiamo realizzato, dai

requisiti all’implementazione, infine offriamo una dimostrazione di un suo possibile uso.

Struttura della tesi

Questo lavoro di tesi è diviso in quattro parti: Introduzione, Nozioni Preliminari, Design

e Implementazione di MaraudersWare, Conclusioni e Sviluppi Futuri. Dopo una breve

introduzione al problema, nella parte Nozioni Preliminari presentiamo quegli ambiti di

ricerca che hanno fatto da sfondo al nostro lavoro.

Partiamo da Sicurezza Adattativa (capitolo 2) che è l’ambito in cui a lungo ha lavorato il

gruppo di ricerca di cui ho fatto parte, continuiamo con Modelli di Spazi (capitolo 3) in

cui esponiamo alcuni formalismi per rappresentare ambienti a diversi livelli di dettaglio:

CityGML e BIM. Nel capitolo 4, Rappresentazione di Spazi, affrontiamo di nuovo il tema

della rappresentazione di ambiente ma sotto un altro punto di vista: ci concentriamo su

formalismi più vicini all’informatica e pensati per ragionare sugli spazi, alcuni (come i

Bigrafi) in maniera sofisticata permettendo anche di ragionare su connessioni digitali. Il

capitolo successivo, Lavori Correlati, presenta dapprima alcune pubblicazioni di ricerca

in cui gli autori, in modi diversi, mostrano come si possa sfruttare la ricchezza semantica

offerta da BIM per migliorare la sicurezza complessiva di un edificio; successivamente

vengono recensiti alcuni software per la gestione della sicurezza fisica, alcuni per la va-

lutazione della stessa in un edificio, altri per il controllo centralizzato dello stato delle

risorse.

La terza parte presenta l’Analisi dei Requisiti (capitolo 6), l’ Implementazione (capi-

tolo 7) di MaraudersWare, una sua Dimostrazione di Utilizzo (capitolo 8) e una Va-

lutazione (capitolo 9). Nel capitolo 6 consideriamo i requisiti funzionali del tool che

abbiamo realizzato fra cui, per esempio, il fatto che sia in grado di importare almeno

parte della struttura di un edificio da un file BIM, identifichiamo alcuni oggetti che ab-

biamo ritenuto rilevanti per le analisi di sicurezza (Telecamere, Personal Computer etc.)

e mostriamo alcuni possibili scenari d’uso. Il capitolo 7 è dedicato all’implementazione

e, dopo aver brevemente introdotto il programma free e open source che abbiamo es-

teso, espone l’architettura generale e le funzionalità del prototipo da noi realizzato. Il

capitolo 8 considera un semplice scenario e mostra l’applicazione di MaraudersWare per

prevenire una violazione della sicurezza. Il capitolo Valutazione presenta pro e contro

del nostro contributo: riscontri positivi da parte dell’unità di business di una compagnia

che collabora con il LERO e aspetti negative ovvero limitazioni del nostro lavoro, queste

riguardano l’ancora immatura compatibilità verso IFC: lo standard di interscambio di

progetti BIM.

Nell’ultima parte, Conclusioni e Sviluppi Futuri, dapprima riassumiamo quanto visto nel

corso della tesi e successivamente esponiamo possibili sviluppi futuri come il superamento

di alcune delle limitazioni o l’ampliamento dell’interfaccia utente di MaraudersWare.

Abstract

Some environments are inherently security-sensitive. We can think for instance of: air-

ports, hospitals, power plants, military sites and so on. In this thesis we consider the

challenge of engineering the design of these kinds of spaces in order to keep security

into account from the very first steps of the life-cycle of a physical space: that is from

its design. Our approach to the problem starts from the idea that security should be

taken into account since the very beginning in the design of a space. For example, we

must be able to assume at design time that a space layout does not allow for violation

of security requirements. Because we are interested in adaptive security, we also want to

be able to take into account potential changes that may occur later and ensure that the

system can react (adapt) automatically to continue to satisfy security requirements. To

do so the systems have to be topology aware and for this reason we talk about Topology

Aware Adaptive Systems. We have performed a literature analysis to discover different

techniques to represent and ways to intend topology. In particular, we focused on the

Building Information Modelling (BIM): the de-facto approach for modelling buildings in

the architecture field. In this work we present a proof of concept tool, which aims at sup-

porting designers in the beginning of the building project and security administrators to

monitor agents and resources inside the building and to discover in advance and prevent

security violations. The proposed tool is developed starting from a pre-existing open

source software for interior design, which was extended to model security relevant fea-

tures and aspects. Moreover, interoperability with existing architectural tools is achieved

through Building Information Model (BIM) and IFC industry specifications support. Se-

curity Analysis is performed via integration with a Threat Analysis tool developed in

our research group.

Keywords: security, topology, aware, adaptive, BIM, design

viii

Contents

Extended Abstract (in Italian) v

Contents ix

List of Figures xii

List of Tables xiv

I Introduction 1

1 Introduction 21.1 The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 The Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

II Background 7

2 Adaptive Security 82.1 Self-adaptive Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Self-adaptive Security Systems . . . . . . . . . . . . . . . . . . . . 92.2 Topology of Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Physical Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Digital Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Topology Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.1 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Ambient Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.3 Bigraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Spatial data models 123.1 CityGML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Building Information Modelling (BIM) . . . . . . . . . . . . . . . . . . . . 13

3.2.1 Historical rationale for BIM: Traditional CAD Limitations . . . . . 143.3 Smart Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 BIM Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 User Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.6 BIM Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.6.1 Autodesk Revit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

ix

Contents x

3.6.2 GraphiSoft ArchiCAD . . . . . . . . . . . . . . . . . . . . . . . . . 173.7 Interoperability and need for Open standards . . . . . . . . . . . . . . . . 17

3.7.1 Green Building XML . . . . . . . . . . . . . . . . . . . . . . . . . . 193.7.2 Industry Foundation Classes . . . . . . . . . . . . . . . . . . . . . . 19

3.8 Industry Foundation Classes . . . . . . . . . . . . . . . . . . . . . . . . . . 203.8.1 Standard Development . . . . . . . . . . . . . . . . . . . . . . . . . 203.8.2 IFC Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.8.3 Visually Explore Ifc Files . . . . . . . . . . . . . . . . . . . . . . . 23

4 Representing Spaces 254.1 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Bigraphs and Bigraphical Reactive Systems (BRS) . . . . . . . . . . . . . 264.3 Ambient Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4 BiAgents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5 Security Process Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.6 Portunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Related Work 335.1 Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Deriving graphs from BIM models . . . . . . . . . . . . . . . . . . 335.2 Ifc BIMs and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2.1 Penetration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2.2 Placing CCTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2.3 Intrusion detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2.4 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3 Physical Security Assessment . . . . . . . . . . . . . . . . . . . . . . . . . 385.4 Physical Security Information Managing . . . . . . . . . . . . . . . . . . . 41

III Design and Implementation of MaraudersWare 43

6 Requirement Analysis 446.1 Introduction and Starting Point . . . . . . . . . . . . . . . . . . . . . . . . 446.2 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2.1 Supporting BIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.3 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.4 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.5 Security Relevant Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.6 Communication Between Modules . . . . . . . . . . . . . . . . . . . . . . . 516.7 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.7.1 Designer check Security of his preliminary scratch . . . . . . . . . . 536.7.2 Security Administrator is informed of Possible Security Violation . 53

7 Implementation 557.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.2 SweeHome3d: A starting point . . . . . . . . . . . . . . . . . . . . . . . . 55

7.2.1 User Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Contents xi

7.2.2 Developer Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 567.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.4 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.4.1 Topology Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.4.2 IFC file Importer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.3 Security Relevant Objects . . . . . . . . . . . . . . . . . . . . . . . 627.4.4 Updating the Internal Representation . . . . . . . . . . . . . . . . 637.4.5 Digital Connections Creation . . . . . . . . . . . . . . . . . . . . . 647.4.6 ABAC Policy Definition . . . . . . . . . . . . . . . . . . . . . . . . 647.4.7 Analysis Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8 A Demonstration of MaraudersWare 688.1 Demonstration Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

9 Evaluation 769.1 Practitioners Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

9.2.1 Rectangular Rooms . . . . . . . . . . . . . . . . . . . . . . . . . . 769.2.2 Name conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 769.2.3 Single Floor Buildings . . . . . . . . . . . . . . . . . . . . . . . . . 77

IV Conclusion and Future Work 78

10 Conclusion and Future Work 7910.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7910.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Bibliography 81

List of Figures

3.1 CityGml Levels of detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 BIM Smart Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 BIM Adoption for country . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Autodesk Revit Screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5 Graphisoft ArchiCAD Screenshot . . . . . . . . . . . . . . . . . . . . . . . 183.6 Interoperability: Role of Open Standards . . . . . . . . . . . . . . . . . . . 193.7 Green Building XML Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.8 BuildingSmart Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.9 IFC Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.10 IfcQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.11 Solibri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Example of Graph to represent house with Big central Kitchen . . . . . . 264.2 Example of Graph to represent Hotel . . . . . . . . . . . . . . . . . . . . . 274.3 Example of Bigraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.4 Example of Place Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.5 Example of Link Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1 Concept of the proposed system . . . . . . . . . . . . . . . . . . . . . . . . 345.2 IFC entities describing structural relationships . . . . . . . . . . . . . . . . 355.3 BIM to graph transformation. . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 Extract of Avert brochure . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.5 Vidsys Open PSIM Platform . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1 MAPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2 MAPE Loop interfacing with and MaraudersWare . . . . . . . . . . . . . 466.3 MaraudersWare Allow Importing BIM Files . . . . . . . . . . . . . . . . . 476.4 Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.5 Monitoring Module communicates with MaraudersWare . . . . . . . . . . 526.6 Analysis Module communicates with MaraudersWare . . . . . . . . . . . . 52

7.1 Screenshot of Sweet Home 3D . . . . . . . . . . . . . . . . . . . . . . . . . 557.2 Gloabl Architecure of MaraudersWare . . . . . . . . . . . . . . . . . . . . 587.3 Simplified Package Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 597.4 Class Diagram of Topology Graph . . . . . . . . . . . . . . . . . . . . . . 607.5 Schema of Internal Graph Representation . . . . . . . . . . . . . . . . . . 607.6 Relationship between Security Extractors . . . . . . . . . . . . . . . . . . 627.7 Class Diagram of Extractor components . . . . . . . . . . . . . . . . . . . 627.8 Class Diagram of Security Relevant Objects . . . . . . . . . . . . . . . . . 63

xii

List of Figures xiii

7.9 Grammar for protocol for communication between Sweet Home 3D + andMonitoring module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

List of Tables

4.1 Pure Mobile Ambient Calculus Syntactic Constructs . . . . . . . . . . . . 31

7.1 Information Exchanged with MaraudersWare . . . . . . . . . . . . . . . . 65

xiv

Part I

Introduction

1

Introduction

Some environments are inherently security-sensitive. We can think for instance of: air-

ports, hospitals, power plants, military sites and so on. In this thesis we consider the

challenge of engineering the design of these kinds of spaces in order to keep security into

account from the very first steps of the life-cycle of a physical space: that is from its

design.

Ensuring security is important for any type of infrastructure but especially for critical

infrastructure [SRD+12]. The Australian Government defines critical infrastructure as:

Those physical facilities, supply chains, information technologies and communication

networks, which if destroyed, degraded or rendered unavailable for an extended period,

would significantly impact on the social or economic well-being of the nation, or affect

Australia’s ability to conduct national defence and ensure national security [Fra08]. The

need to protect such critical infrastructure has become an important priority during the

past decade for governments and industry alike [SRD+12].

Security is about protecting resources from harm [SPO+12], in the context of this thesis

the infrastructure we consider are industrial buildings and the assets to protect are typical

from these spaces like printers, computers, agents and so on.

The problem of engineering security has been addressed in many papers in literature, one

of them is: SERC Systems Security Research Roadmap [Bay10]. In that paper, it was

emphasized that the concept of security should be tangible systems attribute [Bay11]

and should be considered since the requirements specification.

Security requirements are stated as both functional requirements and assurance require-

ments: functional requirements identify what the system must do about ensuring secu-

rity in terms of a system’s technical features and capabilities, assurance requirements

deal with developers responsibilities [Lon07]. In [Bay10] are exposed limitations in the

traditional specification of security requirements and it is advocated the importance of

adaptation in order to efficiently secure a system.

2

Introduction 3

Adaptive systems dynamically change their behavior or structure at runtime to respond

to environmental changes. More specifically, adaptive security systems react to changes

in order to protect valuable assets contained in their operational environment. They do

so by monitoring and analysing this environment, and deploying security functions that

satisfy some protection requirements. A particular class of adaptive security system are

the ones that keep in account the topology of the environment; topology represents a

physical and/or a digital space including its structural relationships, such as containment,

proximity, and reachability. In these kind of systems we can talk about Topology Aware

Adaptive Security .

Collaborations

This thesis is one of the outcomes of the collaboration between the DEIB1 (Department of

Electronics, Information and Bioengineering) of Politecnico di Milano and Lero2 (IRISH

SOFTWARE ENGINEERING RESEARCH CENTRE) of Limerick University. During

my research work for the thesis I had the opportunity to visit Lero and to perform there

part of the literature review and an important part of the development of the proof of

concept tool that we present in this work as main practical contribution. Lero has been

awarded an international contract with United Technologies Research Centre Ireland3

(UTRC-Ireland). UTRC delivers advanced technologies and research to the businesses

of United Technologies (UTC) which provides a broad range of high technology products

and services to the global aerospace and building systems industries. The research group

in which I collaborated is composed distributed between Politecnico di Milano and Lero.

The DEIB part of the group of the group is supervised by Professor Carlo Ghezzi, whilst

the Lero part is supervised by Professor Bashar Nuseibeh.

1.1 The Problem

An important challenge that my research group has been facing is to engineer the design

of spaces in order to keep security in account from the very first steps of the life-cycle of

a building: that is from its design.

In the construction industry, client’s needs and requirements are normally presented in

form of a ‘brief’ document produced as an output to the briefing process. Briefing (archi-

tectural programming in the USA and some other countries) is the process through which1http://www.deib.polimi.it2http://www.lero.ie3http://www.utrc.utc.com

Introduction 4

client requirements are identified and defined, and through which others are informed of

client needs, aspirations and desires for a project [Boa97, SDE09]. Pena and Parshall

in [PP01] define architectural programming as “a process leading to the statement of an

architectural problem and the requirements to be met in offering a solution”.

Our vision it to allow architects and designers to consider security in the early phases

of the design of a building and to validate early-design drafts of building against some

security policies in order to discover security threats and to solve them in programming

phase. It is self-evident that solving a security issue (for example changing the position of

a wall or of a door) at design time is far less expensive then solving it when the building

is already built. The tool we had in mind should approach the problem in a systematic

and formal way this with the rationale of discovering as much security issues as possible.

In our research we investigated the state of the art in the Architecture/Engineering/Con-

struction (AEC) environment, in order to understand which technologies are adopted,

and so for instance what applications they use, what they allow to do. We surveyed some

works in which interplay between architectural technologies and security is considered

but, as far as our findings, there is never interest in preventing security threats at design

time.

We also reviewed software for handling physical security and we have found several com-

mercial implementation of software that allow to perform an evaluation of the security

of a building or to monitor the state assets or agents contained in the space, but we

have found any implementation of software that allow to check security in early stages of

building design. So, from our literature research, from our software overview, and after

briefly consulting with architects in Politecnico, we derived that there is no such kind

of tool, neither there is a formalized approach to the problem of evaluating security in

design phase.

A second goal of our research group is providing security administrators a software that,

supposing the building already well-constructed, allow him to monitor the assets con-

tained inside it and, in case, to detect in advance security threat and possibly to prevent

them.

The first goal concern a more statical problem because it focuses on something happening

in the design phase of the building, whilst the second one has a more dynamic nature

focusing on what happens once the building is available and in use.

Introduction 5

1.2 The Solution

In the last year the research group I had the chance to work with for a few months

has been working, also, in the direction of these two goals (supporting designers to keep

security into account from the beginning of their work, and assist security administrators

to monitor security), and has published some papers in the context of Topology Aware

Adaptive Security like [PGM+14] and [TPM+14].

Our efforts towards the achievement of these goals led to the realization of a prototype

tool that we called MaraudersWare. Before starting the development of the software we

have performed some literature study in the context of topology representation and about

software that handle security of buildings and of their assets. In the first phase of our

research, we have reviewed the state of the art in the architecture context regarding the

representation of buildings and we found that the “de-facto” approach among architects,

and inside the AEC4 community in general, is the BIM5 approach. In a second time

we have reviewed some commercial software used by companies to evaluate the security

or to asses the ease of penetration of a building. This research have helped us not only

to understand the state of the art in these two contexts, but also to formulate some

meaningful requirements. One of the most important requirements of our prototype is

the ability to import some security relevant aspects from BIM models.

The software we have developed provides a Graphical User Interface that can be useful

architects and/or designers and to security administrators. It allows architects and/or

designers to draw a first prototype of the building they need to project and to check this

prototype against some security requirements. It also permits security administrators to

monitor the state of the assets inside the buildings and to discover and prevent security

threats. MaraudersWare is a work in progress, it still has some limitations that will be

presented in the 10 chapter. A great effort has been done to test it against bugs but we

always have to remember Dijkstra’s criticism to testing [Dij72], “Program testing can be

used to show the presence of bugs, but never to show their absence”.

1.3 Thesis Outline

This work is structured in the following way:

• The notion of Topology Aware Adaptive Security in explained in chapter 2: at

first, we define Self Adaptive Security Systems to provide the idea of adaptation4Architecture Engineering Construction5Building Information Modelling

Introduction 6

and then we present the definition of Topology and some techniques to represent

it.

• Chapters 3 and 4 outline different approaches for representing topology: the models

of chapter 3 (BIM, CityGML) are oriented to describing spaces with a certain level

of detail and semantic but without great focus on reasoning on them; on the other

hand formalism in chapter 4 are in general less detailed but they provide different

capabilities of reasoning.

• Chapter 5 reviews some works that for different reasons are related to our work, the

first part of the chapter inspects some publications involving the interplay between

security and BIM whilst the second inspects some commercial applications that

handle physical security.

• Chapters 6 and 7 outline the development cycle of the proof of concept tool we

realized: its requirements definition, its design and its actual implementation.

• Chapter 8 walks through a detailed demonstrating example of use of our tool, we

start from a scenario and we examine the possible contribution of our software to

a Security Administrator.

• Chapter 9 is an evaluation of our work, we expose the feedback we got from indus-

trial partner collaborating with LERO and the limitations of our work.

• Chapter 10 is dedicated to conclusions and future works. Since this thesis is devel-

oped in a broader context that, for instance, involves business collaboration that

potentially can last for the next years, it is natural to imagine how this work will

be further expanded.

Part II

Background

7

Adaptive Security

This chapter aims to define the context in which this thesis is born. The core idea

of this work is that a system in which security is a critical requirement should have a

certain degree of adaptation against threats. For this reason we present Security and

Adaptation as background concepts of our work. In this chapter we briefly outline the

notion of Self-adapting Systems, we state the importance of context awareness for them

and in particular we propose Topology as a key element in context. In the last part of

the chapter we give an idea of some approaches for representing topology.

2.1 Self-adaptive Systems

Self-adaptive systems are able to adjust their behaviour in response to their perception

of the environment and of the system itself. [CdLG+09]

The ability of a system to change is exploited in several application areas and technolo-

gies, such as: adaptable user interfaces, autonomic computing, dependable computing,

embedded systems, mobile ad hoc networks, mobile and autonomous robots, multi-agent

systems, peer-to-peer applications, sensor networks, service-oriented architectures, and

ubiquitous computing. It also hold for many research fields, which have already investi-

gated some aspects of self-adaptation from their own perspective, such as fault-tolerant

computing, distributed systems, biologically inspired computing, distributed artificial in-

telligence, integrated management, robotics, knowledge-based systems, machine learning,

control theory, etc. [KK13]

Adaptation can be enabled by context awareness. Applications, services or artefacts

said to context aware are capable of understanding their physical environment or sit-

uation. Moreover they can respond proactively and intelligently based on such aware-

ness [BZMK09]. There are several different definitions of context in literature, for in-

stance Anin in [Dey01] defines it as “any information that can be used to characterize

the situation of an entity”. Examples of context are given for instance by location,

time-of-day, user activity, battery level (for mobile applications).

8

Adaptive Security 9

2.1.1 Self-adaptive Security Systems

Engineering self-adaptive systems that continue to satisfy their security requirements

has been recently recognised as an important challenge to be addressed by the software

engineering community [SPO+12, YM12].

2.2 Topology of Spaces

In our research, we have proposed topology as a rich form of context that the system

can take advantage of, in order to establish how to efficiently adapt.

Physical and Digital Topologies

In a physical sense, a topology denotes the physical characteristics of a space, such as

size, adjacency, and connectivity, and is often represented as a map or physical model. In

a digital sense, a topology often denotes structural characteristics of information, such as

logical relationships between entities in an information model. In both cases, structural

relationships are key, such as hierarchy, containment, proximity and reachability.

2.2.1 Physical Topology

A physical topology represents the location of physical agents (e.g., humans, robots) and

objects in a physical environment (e.g., a building) and their structural relationships

(e.g., agents-objects proximity) Physical topology in the context of adaptive security is

proposed in [TPM+14]

2.2.2 Digital Topology

A digital topology represents the configuration of a virtual environment, such as a net-

work, which may be composed of nodes (e.g., physical and virtual machines), including

their hardware and software configuration and network connections.

In our research group some studies have been conducted about the interplay between

Physical and Digital spaces, always in the context of Adaptive Security. In fact, since

computing and communication capabilities are increasingly being embedded into physi-

cal spaces, the boundary between cyber and physical worlds is becoming blurry [Lee08],

and the opportunities for malicious agents to attack such systems are therefore increasing

Adaptive Security 10

[DPS+05]. In literature there is no great attention to the interplay between cyber and

physical security, but we advocates that, in the face of this, this interplay is potentially

interesting to discovering possible security violations. For example,cyber-enabled phys-

ical attacks can occur when physical assets are cyber-controlled, such as software that

controls access to buildings or some of their areas. Similarly, physically-enabled cyber

attacks can occur when physical access to assets or locations enables cyber attacks. For

example, access of an agent to a physical area from which it is possible to connect to a

wifi network, enables the agent to eavesdrop on other agents’ information transmitted

over the network [TPM+].

2.3 Topology Representation

Self-adapting systems rely on software not only in order to be aware of their own en-

vironment, but also to reason on it and then to derive adequate decisions in order to

change their behaviour, if necessary. For this reason, eventually, topology has to be

translated into a data structure inside the software. We briefly outline three approaches

to represent topologies, systematic reasoning is enabled by a formal representation.

2.3.1 Graphs

From a computer science point of view, probably, the most intuitive way to represent

topology is using graphs: trivially in order to describe a building it seems quite natural to

use nodes to represent rooms and edges to represent connections between rooms. In fact

Janusz Szuba in his PhD thesis [Szu05] shows the use of this approach from architects

and designers.

2.3.2 Ambient Calculus

Ambient Calculus is a process algebra that can be used to describe so-called “ambients”:

intuitively they are bounded spaces where computation happens, ambients can be nested

within other ambients and have a collection of local agents [CG98]. Nesting ambients it is

possible to describe hierarchical structures; that structures are the only supported by this

process algebra. Using Ambient Calculus, hierarchical structures can be reconfigurated

with relatively low complexity. These reconfigurations, however, have a certain, limited,

degree of freedom and for instance there is no way to arbitrarily define them.

Adaptive Security 11

2.3.3 Bigraphs

To overcome this limitations, without loosing the possibility to reason about mobility

and security, it is possible to adopt another formalism: Bigraphs. A bigraph consists

of two superimposed structures: a place graph representing locality and a link graph

representing connectivity [Mil01]. Exploiting the link graph, for instance, it is possible

to describe a wireless connection between a personal computer and a printer, or between

a cellphone and a wi-fi router.

Spatial data models

A spatial data model defines how spatial data are stored and represented within spatial

databases. [SRD+12] Spatial data model, in several levels of abstraction, can be used

to define physical topology of a “space”, this space can be something vast like a city

or something more restricted as the interior of an apartment. There two categories of

spatial data models depending on their specialization: the ones regarding indoor and

the ones regarding outdoor environments. In this chapter we are presenting CityGML

as an example of outdoor spatial data model, but our literature analysis is especially

focused on indoor SDM and namely in BIM, in open standards used to exchange BIM

models and in particular in the IFC one because is the one we have supported in the

implementation of MaraudersWare.

3.1 CityGML

CityGML is a common information model and XML-based encoding for the representa-

tion, storage, and exchange of virtual 3D city and landscape models.1 From a technical

point of view, CityGML is implemented as an application schema of Geography Markup

Language (GML) that is developed and maintained by the Open Geospatial Consortium

(OGC), which is an international consortium consisting of more than 250 members from

industry, government, and university departments. [Bur06]. This assures a good level

of Syntactic interoperability among the whole family of GML-compatible OGC web-

services like: the Web Feature Service, Web Processing Service, and the Catalog Service.

CityGML allows different perspectives of the city, in fact, it provides appearance, topo-

logical, semantic and geometrical models that in CityGML jargon are called “thematic

classes”. It is possible to represent a great variety of urban objects such as built struc-

tures, elevation, trees, water bodies, and even transportation facilities like streets and

railways.1http://www.citygml.org/index.php?id=1523

12

Spatial data models 13

To facilitate different application requirements CityGML. LoD0 is a terrain model. LoD1

buildings are modelled as simple extruded blocks. LoD2 contains the same extruded

blocks with some roof structures defined (as well as simple balconies and stairs). For

LoD2 in specific the CityGML standard specifies a positional and height accuracy of at

least 2m. True architectural models can be defined in LoD3, with which also detailed wall

structures, roofs, windows and doors can be modelled. LoD4 is the only Level of Detail

(LoD) in which interiors of buildings are modelled, with structures as rooms, stairs and

furniture. [Boe13] An example of different granularity of LoDs is shown in Figure 3.1

Figure 3.1: Different levels of detail in CityGml [Grö08]

3.2 Building Information Modelling (BIM)

The term BIM is used both as a verb and as a noun, that is Building-Information-Model

and as Building-Information-Modeling. So, BIM accounts for the various human prac-

tices (i.e. activities, processes, norms and values) that ‘formulate building information

models’[JHMR14]. The model stored in the BIM files can be also referred as BIModel.

BIM is a rich-semantic object-based methodology that can be adopted in AEC/FM2

during all the life-cycle of a building. In this section at first we present historical mo-

tivation for its creation, then we outline some core features, we talk about the problem

of integration different implementation that leads to the need of open standards. We

then present two proposed standards: IFC and GreenXML, much more space is given to

IFC since it is the de-facto standard for interchange. The two most influencing, market

leading, software are then briefly reviewed and finally we present some criticism and

limitation to BIM.2Architects Engineers Constructors and Facility Management


3.2.1 Historical rationale for BIM: Traditional CAD Limitations

Although the manual referencing of paper based product data and building design has

existed for centuries, it was the increasing use of CAD facilities in design offices from

the early 1980s which prompted the first efforts in electronic integration and sharing of

building information and data [RBWC11]. The core problem is that CAD is mainly used

as a digital drafting board rather than as a design tool. CAD data remains mainly in the

form of 2D geometry data, compiled by entity-based CAD software such as AutoCAD

and MicroStation. The whole building model is therefore simply represented by raw

graphic entities or primitives (e.g. lines and arcs), which cannot provide rich semantic

meaning about the building. [TWW05] In the traditional CAD approach, therefore, the

architect has to interpret the meanings of what has been drawn, in the exact same way as

with physical drawings. This lack of semantic does not permit the sharing of knowledge

and information that in turn leads to errors in all the phases of the project. Design errors

are claimed to account for 26% of the cost of defects. A variety of approaches and meth-

ods for reducing design errors have been suggested, and recently building information

modelling (BIM) has been considered as a mean for reducing design errors, for example

by automated clash detections [LPG14].

3.3 Smart Objects

In BIM CAD, the building components are objectified. Digital objects are coded to

describe and represent real life building components. For example, a wall object is an

object that understands the properties of walls and acts as one. Instead of represent-

ing a wall two-dimensionally with two parallel lines, the wall object has properties that

describe geometrical dimensions such as length, width and height as well as materials,

finishes,specifications, manufacturer and price which are also included. Doors, windows,

slabs, structural members, and stairs can be objectified in the same way [IKS04]. Essen-

tially, a BIM is a shared representation and spatial database that records the location

and attributes of every component

3.4 BIM Uses

BIM can be exploited in a great variety of applications such as:

• Design Visualisation

• Design assistance and constructability review


Figure 3.2: Building Information Models and their objects — flow diagram.[Suc09]

• Site Planning and Site utilisation

• Scheduling and Sequencing (4D)

• Cost Estimating (5D)

• Integration of Subcontractors and supplier models

• Systems coordination

• Layout and fieldwork

• Prefabrication

• Operations and Maintenance (including as-built records)

[Cam07]

In literature BIM implementations that allow to take in account time and costs are

defined as 5DBIM (For instance in [Mit12])

3.5 User Adoption

McGraw Hill Construction recently published its first SmartMarket Report on the adop-

tion and use of Building Information Modeling (BIM) for construction projects world-

wide. The report focuses on nine of the world’s 10 largest construction markets - Australia

and New Zealand, Brazil, Canada, France, Germany, Japan, South Korea, the U.K., and

the U.S. 3 In this report the authors survey the state of the art concerning BIM maturity

adoption, awareness and several other parameters, on geographic base. In particular it

is interesting to consider the percentage of user that have been using BIM in order to

understand its impact on the global market.3http://www.aconex.com/blogs/2014/01/global-state-of-bim-construction-market-data.html


Figure 3.3: Length of Time Contractors Have Been Using BIM (By region/Country)

BIM mandates growing

As adoption of BIM increases, the use of digital models for virtual design, construction,

and collaboration is becoming standard, and governments, organizations, and owners

around the world are mandating BIM on new building projects. For example:

• In early 2014, the European Parliament approved a Directive for Public Sector

Procurement that encourages public authorities to consider using BIM in public

works and draws attention to the opportunity and benefits that BIM presents to

public construction projects. BIM Mandates Growing

• By 2016, the UK government requires all government projects to utilize collabora-

tive 3D BIM. Since the government accounts for approximately 40 percent of UK

construction capital expenditures, this is an aggressive BIM mandate.

• The General Services Administration (GSA) builds and manages federal facilities

and, as such, is the largest owner of commercial space in the United States. They

began requiring the delivery of building information models for major federal build-

ing projects in 2006.

• Since 2008, the U.S. Army Corps of Engineers requires the use of BIM for all

military construction projects to improve construction time and costs.

[Con14]


3.6 BIM Software

According to [MM13, ANML08] the most relevant BIM software platforms are Autodesk

Revit and GraphiSoft ArchiCAD

3.6.1 Autodesk Revit

Revit building design software is specifically built for Building Information Modeling

(BIM), with features for architectural design, MEP and structural engineering, and con-

struction.Bring ideas from concept to construction with a odel-based approach. 4

Figure 3.4: Autodesk Revit Screenshot

3.6.2 GraphiSoft ArchiCAD

ArchiCAD is an architectural BIM CAD software for Macintosh and Windows developed

by the Hungarian company GRAPHISOFT. ArchiCAD offers computer aided solutions

for handling all common aspects of aesthetics and engineering during the whole design

process of the built environment — buildings, interiors, urban areas, etc. 5

3.7 Interoperability and need for Open standards

The AEC industry is comprised of many diverse disciplines, such as architecture, struc-

tural and HVAC engineering, cost estimation, and construction and facility management.4http://www.autodesk.com/products/revit-family/overview5http://en.wikipedia.org/wiki/ArchiCAD


Figure 3.5: Graphisoft ArchiCAD Screenshot

According to IEEE, interoperability is “the ability of two or more systems to exchange in-

formation (needed and available) and use it”[RGK90]. The problem of interoperability in

the context of projecting buildings, is probably as old as the AEC itself; in 1999 Zamanian

published an article on this topic raising the problem of information modelling[ZP99].

Technology has hugely evolved since 1999, but the interoperability inside AEC is still

challenging as advocated in [KI15].

All stakeholders (architects, engineers, designers, surveyors, contractors, etc.), working

in a given project phase, use computer applications which consume and/or supply infor-

mation processed by different software employed by other collaborators on that phase.

Each pair of communicating applications must be able to access (insert, extract, update

or modify) a subset of the information created by the other (one- or two-way). [JGG10]

Historically, the construction industry has operated without commonly used, open stan-

dards for sharing data, instead it has relied on proprietary formats inherently bound to

a specific BIM software vendor.

If no common open standard exists, each individual software application must develop

and implement direct translators back and forth for all other pieces of software which it

seeks to communicate with in order to convert the mappings from the internal application

format to the target formats. If an open standard can be used instead, the mappings

only need be translated back and forth from that single format in order to be compatible

with all other applications supporting that same standard. [LK12] This conceptual

representation of the two scenarios is depicted in

3.6.

In 19946 and in 1999 7 Green Building XML (gbXML) and Industry Foundation Classes

(IFC) open standards have been released.6http://www.gbxml.org/history.php7http://en.wikipedia.org/wiki/Industry_Foundation_Classes


Figure 3.6: Interoperability: Role of Open Standards [LK12]

3.7.1 Green Building XML

Green Building XML is an open schema developed to facilitate the transfer of informa-

tion in the BIM to engineering analysis tools. From its development in 1999 and first

publication in 2000, gbXML has been supported by a number of leading BIM software

vendors. [CD14]

3.7.2 Industry Foundation Classes

IFC development started in late 1994 with the creation of the (then-named) Indus-

try Alliance for Interoperability. On becoming worldwide, IAI changed its name to

International Alliance for Interoperability and now it is called buildingSMART Interna-

tional. Therefore, IFC, named after the first IAI denomination and now in this ninth

version (2x4), is more than a decade-old initiative, whose first version was published in

1997 [Khe04]. According to buildingSMART official site8, more then 100 developers or

vendors support IFC giving the possibility to import or export in this format; not sur-

prisingly this is also true for the aforementioned BIM applications Revit and ArchiCAD.

It is worth noting that as a schema IFC cannot provide interoperability by itself - it relies

on how software packages interfacing with it. Most modern BIM authoring platforms

support import and/or export of IFC model data and buildingSMART International

certifies applications that comply with the standard. This flow of information is critical

for collaboration and interoperability because it connects different downstream applica-

tions, for example facilities management, structural modelling and performance analysis

applications.8http://www.buildingsmart-tech.org/implementation/implementations/plominoview.vendors


Figure 3.7: Green BuildingXML Logo

Figure 3.8: BuildingSmart Logo

3.8 Industry Foundation Classes

3.8.1 Standard Development

The process that brought to the definition of IFC is quite long and started in 1984 when

the TC184/SC4 subcommittee of ISO declared that none of the existing formats could

on their own be extended to serve the needs of an open computer modeling standard

for multiple industrial and manufacturing industries[Ver96]. That point marked the be-

ginning of the development of the Standard for the Exchange of Product Model Data

(STEP). The AEC/FM industry was just one of several industries included for standard-

ization within STEP. SC4 recognized that robust data modeling was central to supporting

the complexity of STEP, and after some evaluation, existing modeling languages were

deemed incomplete or unsuitable for the requirements of STEP. Thus began an effort to

develop a language that later became known as EXPRESS. [LK12] EXPRESS is a data

definition language that can be used to define entity relationship models, this models can

be depicted in the EXPRESS graphical notation called EXPRESS-G. While EXPRESS

defines a way to represent schema for data, STEP defines how to describe instantiated

entities, STEP files are in a sense “realizations” of EXPRESS schema, for this reason

they are also called STEP-physical files, to highlight the fact that they are “concrete”

entities of a schema. The IFC, intended as abstract specification is written in EXPRESS,

while IFC files are textual files in ASCII format that follow the STEP specifications, so

an IFC file is an instance of the IFC schema written under the STEP rules.

From a syntactical point of view, a STEP (and thus IFC) file defines entities as objects

with a set of attributes, where each object is assigned a unique identifier that is used

when referencing the object. Each line in the data section defines a new object, where

the identifier is given on the left side of the equals sign and the right side defines the

object type followed by a set of ordered attributes. Each attribute may be a string, an

object reference (e.g. “#10”), or a null value $ [AK].


#20043= IFCEXTRUDEDAREASOLID (#20041 ,#20042 ,#19 ,2.75);

#20044= IFCSTYLEDITEM (#20043 ,(#7303) , $);

#20047= IFCSHAPEREPRESENTATION (#87 ,\’Body’,’SweptSolid ’ ,(#20043));

#20049= IFCPRODUCTDEFINITIONSHAPE($, $ ,(#20036 ,#20047));

#20051= IFCWALLSTANDARDCASE(’2egqJmChD8kuJZODZ6O4$j ’ ,#41,

’Basic Wall:Ext. Voile BA 20 +

Isolant 10:239945 ’,$,’Basic Wall:Ext. Voile BA 20 + Isolant 10:29321 ’,

#20031 ,#20049 ,’239945 ’);

#20054= IFCMATERIALLAYERSETUSAGE (#7374 ,. AXIS2.,.NEGATIVE . ,0.16);

#20055= IFCPROPERTYSINGLEVALUE(’Unconnected Height ’,

$,IFCLENGTHMEASURE (2.75) ,$);

#20056= IFCPROPERTYSINGLEVALUE(’Area’,

$,IFCAREAMEASURE (3.01348896172753) ,$);

Listing 3.1: Excerpt data from an IFC BIM model stored in STEP physical file format

3.8.2 IFC Data Model

The structure of the IFC data model was divided into four layers: domain, interoper-

ability, core, and resource layers.

The layers have strict referencing hierarchies, the main rule of thumb being that refer-

encing can only occur downwards in the hierarchy. This means that data in the resource

layer must be independent and reference no classes above it. The other layers, however,

can all reference data from the resource layer as well as all other layers below them.

References within the same layer are allowed only for the resource layer. The resource

layer holds the resource schema that contains basic definitions intended for describing

objects in the above layers. The core layer consists of the kernel and extension modules.

The kernel determines the model structure and decomposition, providing basic concepts

regarding objects, relationships, type definitions, attributes and roles. Core extensions

are specializations of classes defined in the Kernel. The interoperability layer provides

the interface for domain models, thus providing an exchange mechanism for enabling

interoperability across domains. The domain layer contains domain models for processes

in specific AEC domains or types of applications, such as architecture, structural engi-

neering, and HVAC, among others. [LK12] Figure 3.9 recaps the IFC layers structure.

Each entity defined in the core, interoperability, domain or resource layer of the IFC

model inherits (over some intermediate steps) from the IfcRoot entity that stores a

globally unique identifier (the GUID) and a name which should be a user recognizable

label for the object occurrence. There are three fundamental entity types in the IFC

model, which are all derived from IfcRoot. They form the first level of specialization

within the IFC class hierarchy.


Figure 3.9: Ifc Structure [LK12]

objects (IfcObject) are the generalization of any semantically treated thing (or item)

within the IFC model.

relations (IfcRelationship) are the generalization of all relationships among things

(or items) that are treated as objectified relationships in the IFC model.

properties (IfcPropertyDefinition) are the generalization of all characteristics that

may be assigned to objects.

While being true that thousands of IFC entities exist, a small number of them is already

sufficient to perform a basic description of the physical topology of a building. We present

here some IFC entities (objects and objectified relations) that are can be useful to this

purpose.

IFC Object Entities

IfcSpace By IAI definition a space “represents an area or volume bounded actually or

theoretically”, more concretely, from our literature review (for instance: [LWL+13,

SRD+12, PTTW14]) we can assert that the IfcSpace entity is commonly used to

represent rooms inside buildings.

IfcProduct IAI defines IfcProduct as “any object, or any aid to define, organize and

annotate an object, that relates to a geometric or spatial context.” Every IfcProd-

uct has two attributes defining its shape and location: Object-Placement (of type

IfcObjectPlacement) and Representation (of type IfcProductRepresentation) re-

spectively. Subtypes of IfcProduct are, for instance, IfcBuildingElement, IfcWall,

IfcDoor.


IfcBuildingElement From IAI, IfcBuildingElement “comprises all elements that are

primarily part of the construction of a building”, so core objects in the architectural

field such as: ramps, walls, columns, beams, stairs, roofs etc.

IfcBuildingElementProxy A special case of IfcBuildingElement is given IfcBuildin-

gElementProxy.Several BIM applications can export a project in IFC format, dur-

ing the exportation process, every time it is found an object for which there is not a

predefined type in the IFC schema, an IfcBuildingElement is created as placeholder

for it. A meaningful name is assigned by the BIM application, if possible.

IfcWall IAI states that “The wall represents a vertical construction that bounds or

subdivides spaces”. IfcWall are specialized in IfcWallStandardCase that are walls

with fixed thickness.

IfcDoor IAI defines a door as “ a building element that is predominately used to provide

controlled access for people and goods.”

IFC Objectified Relations

ContainsElements Every IfcSpatialStructureElement, and so also every IfcSpace that

specializes it, has an object attribute called ContainsElements of IfcRelContainedInSpa-

tialStructure type. This object, in turn, has a RelatedElements attribute that is

a list of IfcProduct. Traversing this objects it is possible to know all the products

contained inside a room.

BoundedBy This object attribute belongs to every IfcSpace and encapsulates a set of

IfcRelSpaceBoundary: each member of the set representing a “bounding” room that

is a room that shares a wall with the IfcSpace. Traversing IfcRelSpaceBuondary

attributes it is possible to know which rooms are connected with the considered

IfcSpace and by mean of which walls.

HasOpenings Every IfcElement (a subtype of IfcProduct) has an attribute called Ha-

sOpenings which encapsulates a set of IfcVoidsElements. Since an IfcWall is a

subtype of IfcElement, it has the HasOpenings attribute as well and traversing the

attributes of the HasOpenings object it is possible to understand whether a door

is inside a wall or not.

3.8.3 Visually Explore Ifc Files

There are several tools that allow to graphically visualize the building described by an

Ifc file and to explore the interplay between Ifc entities and graphical representation.


Figure 3.10: IfcQuery

Figure 3.11: Solibri

A prime example of this kind of software is Solibri Model free, it provides a very good

view of the underlying building depicted in the Ifc file it can receive as input. Another

free software for graphically displaying Ifc files is IFC++9. Using IFC++ it is possible

to understand some complicated properties of the Ifc data format, for instance in our

research work it has been useful to traverse objectified relations of Ifc entities.

9https://code.google.com/p/ifcplusplus/

Representing Spaces

Representing spaces is a precondition for reasoning on them. In the context of our work,

reasoning on spaces is important to discover in advance security threats; nevertheless

describing and speculating about spaces can be useful in many other contexts. In this

chapter we present some approaches to this problem: we start from the famous formalism

of graphs applied in architectural programming, then we present other formalisms that

have found application in the field of security. A fair amount of space is dedicated to

Bigraphical Reactive Systems (BRS) because the Threat Analysis module, developed in

our research group, that interfaces with the tool we propose in this work, is based on

them.

4.1 Graphs

Graphs are a natural representation of spaces used by designers. In many handbooks for

designers we can find graphs describing the functionality or decomposition of a designed

object.They appear very often in the conceptual phase of design, where designers still

operate at a very high level of abstraction [Szu05]. Designers, especially architects, very

frequently use graph structures to represent the functional and spatial relations of the

object to be designed [Szu05]. We present here two images as possible examples of

graphs used by designers, in [Szu05] Szuba fulfill a complete survey about graphs in

design and in Chapter 6, he presents a great variety of pictures. Pictures are taken from

[NAD90, NNG98] and adapted by Szuba who has replaced the original text with english

text.

In Figure 4.1 is shown a graph representing the spatial structure of classes of apartments

with big central kitchen. Every node is a room that can be necessarily present (and so

with solid line), or present only in in big houses (and so with dotted line). There are

two types of links: to denote visibility or communication (mutual reachability), so for

example from the Entrnace it is possible to see the Kitchen and to reach the Garden

Gate.

25

Representing Spaces 26

Figure 4.1: Example of Graph to represent Houses with big central Kitchen

Figure 4.2 is an example of a more complex building modelled, in particular a hotel. Also

in this case nodes are rooms, they can belong to service area or to public area. There is

no explicit information about links but likely they are used to describe connectivity or

adjacency between rooms.

4.2 Bigraphs and Bigraphical Reactive Systems (BRS)

Bigraphs is a formalism consisting of two graphs. which is a formalism consisting of two

graphs. A place graph is a forest, capturing the notion of containment and nesting of

physical and digital locations. A link graph is a hypergraph composed of the same set of

nodes of the place graph and a set of edges each linking any number of nodes; this graph

represents generic many-to-many relationships among nodes, such as communication

among digital objects and agents [Tsi15]. Each node is assigned a control that is a name

denoting its type, each node control can be associated with a number of named ports.

We show an example of Bigraph (Figure 4.3) and its related place graph (Figure 4.4)

and link graph (Figure 4.5). The bigraph representation used for the scope of this thesis

is found in Formulae 1a-1e, and is used to represent the floor plan of the demonstrating

example in chapter 8.

P.Q Nesting (P contains Q) (1a)$i Site numbered i (1b)

K[a, b].PNode associated with control K having ports a and b.The node contains P

(1c)

P ||Q Juxtaposition of roots (1d)P |Q Juxtaposition of children (1e)


Figure 4.2: Example of Graph to represent Hotel


We explain this Formulae referring to Figure 4.3. P and Q are bigraphs. The containment

relationship is expressed in Formula 1a; for example, Bob contains a mobile phone him

carries. Additionally, bigraphs can contain sites (Formula 1b) that can be used to denote

placeholders. If a single instance node of a control type exists in the bigraph, the control

also uniquely identifies that node (e.g., for the Hose). Otherwise, port names can be used

as a way to uniquely identify a node (e.g., for rooms, or people). Since the underlying

link graph is a hypergraph, multiple different ports may be related to a single name; ports

of different nodes occuring in a formula with the same name, are considered connected.

For example, Cellphones can have port wifi indicating they are connected to the wireless

network (note the Wif i router having also a port named wifi). Bigraphs can be contained

in roots that delimit different hierarchical structures. In Formula 1d, P and Q are

different roots; they can reside in different parts of the containment hierarchy. Conversely,

two bigraphs can be placed at the same hierarchical level , as shown in Formula 1e. For

example, nodes representing the Pc and the Cellphone in the Bedroom are colocated.

(adapted from [Tsi15])

BRS extend bigraphs by representing the dynamic behavior of the operational environ-

ment as a set of reaction rules. These rules have the general form of R → R′, where R

is a redex and R′ is a reactum; both the redex and reactum are bigraphs. In particular,

if a part of a bigraph matches a reaction redex, it can be replaced with the reactum, in

a fashion similar to graph rewriting.

A brief example of Bigraph notation is given in Listing 4.1, it is described a simple build-

ing (House) composed by three rooms (Diningroom, Kitchen and Bedroom). Bob and

Alice are in Diningroom, Bob is holding a smartphone (Cellphone-1) that is connected

with the Pc located in the Bedroom via wifi connection; the same Pc is connected with

another smartphone (Cellphone-2) via bluetooth. The wifi connection is provided by a

Router located in the Kitchen.

House .(

Room[Diningroom ].( Agent[Bob ].( Cellphone -1[ wifi]) | Alice )

| Room[Kitchen ].( Router[wifi])

| Room[Bedroom ].(Pc[wifi , bluetooth], Cellphone -2[ bluetooth] ) )

Listing 4.1: Example of Bigraphs notation. In Figure 4.3 is represented its intuitivemeaning


Figure 4.3: Graphical representation of the Bigraph depicted in Listing 4.1

Figure 4.4: Place Graph underlying to 4.3


Figure 4.5: Link Graph underlying to 4.3

4.3 Ambient Calculus

Ambient calculus is a process algebra with a special focus on mobility [CG98]. It aims to

describe and analyze the evolution of systems, which consist of elements called ambients

which interact among each other, and whose configuration is continually changing. An

ambient is an abstract entity that can be used to model different elemenets, such as

machines, mobile agents, processes or assets [Mil91]. In this sense, in the following we

will use ambients and processes as synonyms. Compared to the traditional π calculus,

ambient calculus consider movement of processes rather than comminication [NHN03].

Ambients reside in a hierarchy of location and form a tree structure that can be dynam-

ically reconfigured by exercising the capabilities in, out and open.

4.3.1 Syntax

Since we have not used Ambient Calculus in our work, we do not present its complete

syntax, but we just focus on its basic constructs that are summarized int table 4.1

A process P can simply do nothing (formula 1b), can be decomposed in two processes

running in parallel (formula 1c), or can be enclosed into an ambient which is a particular

kind of process (formula 1d). A process can also execute a capability and then proceed

to the execution of another process. We assume that the capabilities available are in and

out (formulae 1e and 1f, respectively) [TPM+14].


P,Q,R ::= processes (1a)| 0 inactivity (1b)| P |Q parallel composition (1c)| M [P ] ambient (1d)| in n capability to enter n (1e)| out n capability to exit n (1f)

Table 4.1: Pure Mobile Ambient Calculus Syntactic Constructs

As a syntax example, in Listing 4.2, we describe the simple building presented in the

previous section using Ambient Calculus. Note that the process algebra does not provide

a standard way to model connections.

House[ Diningroom[Bob[Cellphone -1] | Alice]

| Kitchen[Router]

| Bedroom[ Pc | Cellphone -2]]

Listing 4.2: Example of Ambient Calculus notation

We can assume that agents can perform capabilities, depending on their locations; for

instance an agent can exit (out) from the room he is located. Referring to the afore-

mentioned example, Bob can perform out capability that implies a reconfiguration of the

hierarchy: the result of this reconfiguration is showed in Listing 4.3.

House[ Bob

| Diningroom[Bob[Cellphone -1] | Alice]

| Kitchen[Router]

| Bedroom[ Pc | Cellphone -2]]

Listing 4.3: Hierarchy of Listing 4.2 after reconfiguration caused by capability exitperformed by agent Bob

4.4 BiAgents

BiAgents [PKS12] are a model for computational systems embedded in a physical world.

It focuses on physical worlds that change structure, such as environments with moving

people or vehicles, nomadic programs, or changing connectivity between entities as caused

by vehicles moving in and out of wireless range. In this model computational or virtual

entities are agents and the physical entities are expressed as a bigraph. Entities, such as

vehicles, persons, computers or smartphones are nodes of the bigraph placing or linking

graph. Agents interact with the bigraph by observing it, being hosted in it, migrating in it

and controlling it. Control actions are expressed as bigraph reaction rules. BiAgents are

able to observe the physical structure, and map observations to controls and migration

actions. Since BiAgents operate over a shared environment some ill-defined behaviors


may emerge due to concurrency. Therefore strategies are proposed for preventing these

behaviors based on avoiding interleaving between observation and control and based on

partitioning the physical structure where each agent operates in its own region. However

in a BiAgents model the separation among the components spanning the two spaces

is clear, and their interaction is fairly limited. Therefore BiAgents are not suitable to

identify security breaches that can arise from the interplay between cyber and physical

spaces.

4.5 Security Process Algebra

For some cyber-physical systems security breaches might be determined by the compo-

sition of physical systems with cyber components. Indeed, sensitive information about

a physical component can be inferred through behavior observation about related cyber

components. The security Process Algebra [FG97] allows defining complex cyber-physical

systems in a bottom up fashion. Components actions can belong to two different levels of

confidentiality, permitting the specification of two-levels systems. Akella et al. [Mad13]

use SPA to define a composite model of the CPS and confidentiality properties are ex-

pressed as bisimulation-based non-deducibility, i.e. low level events observations from

physical elements should not be affected when these are composed with cyber compo-

nents. Automated detection of confidentiality breaches is performed by using the CoPS

model checker [PPR04].

4.6 Portunes

Portunes [DPH10] is a framework capable of representing attacks scenarios spanning the

physical, digital and social domains, with particular interest to insider threats. Portunes

is able to represent 1) physical properties of elements, 2) mobility of objects and data,

3) identity, credential and location based access control and 4) trust and delegation

between people. The language adopted to represent potential insider threats extends

KLAIM dialects [DNFP98]. Although this work is effective in simulating the feasibility

of insider threats it cannot suggest adequate security measures to mitigate identified

insider threats.

Related Work

The main practical contribution of our work is the development of MaraudersWare. The

tool is presented in detail in chapters 6 and 7. In this chapter we will review some

literature works that are in some way related to our prototype product.

The first section, Spaces, recaps some publications of authors interested in deriving a

topology graph from IFC files: this works are related with our contribution because

MaraudersWare can import the structure of a building from a BIM IFC file and once the

file is imported a graph representing the building topology is derived.

The second section, Ifc BIMs and Security, reviews some works in which BIM is used in

the context of security, the relation with our work is that we also exploit BIM to derive

some basic informations about topology and assets in the building object of the security

analysis.

The third and fourth section are about Software Managing Physical Security and expose

some commercial softwares used in the context of physical security, some for evaluation

of security of a building and other for checking in real time the state of security; our tool

is a work in progress, but, at least conceptually, it lays in the middle of these two software

categories. On one hand MaraudersWare can be used in the design phase of a building

in order to discover some potential threats to security, and this is, in a sense, evaluation;

on the other hand MaraudersWare can be used when the building hosts employess and

assets to monitor them, and this is closer to the second category of reviewed software.

5.1 Spaces

5.1.1 Deriving graphs from BIM models

Graph-based retrieval of building information models for supporting the early design

stages is an article published in 2013 [LWL+13]. The aim of the authors research is to

provide support to deigners in the early phases of the architectural design process. They

33

Related Work 34

consider the traditional approaches in the design phases of a building and suggest that

an issue in the current state of the art in design phase is the lack of a good specialized

search engine.

Tha authors envision is an instrument allowing a designer to efficiently search for build-

ings starting from a graphical sketched representation she has in mind. In a high level

of abstraction, there thre macro-steps to perform in order to implement this kind of

search: the first one is translating into a graph1 the sketched representation of the de-

signer, the second one is translating building projects already in BIM format (stored

online, for instance in the cloud) into graphs, and finally compare each graph of building

with the sketched representation in order to propose relevant results. These graphs are

used as “fingerprints” meaning that every building, in authors assumptions, is univocally

characterized by its topology graph.

Figure 5.1: Concept of the proposed system to extract semantic fingerprints frombuilding information models and the user sketch to perform similarity assessment by

graph matching. [LWL+13]

From our perspective the most relevant part of their work is the extraction of the graph

starting from an IFC file. They do so interpreting the relations between entities that

are modelled inside the IFC file, following the IFC specifications it is possible to infer

the basic structural information about the building. For instance IfcRelFillsElement and

IfcRelVoidsElement are used in conjunction to recognize the relationship of an opening

or a door to a wall, and then again to check the relationship of the wall to the adjacent

rooms.

The relations of the IFC entities required to compute the topological relationships of

spaces are depicted in Figure 5.21In this section the term graph is used as compact notation to denote a topology graph of a building

in which every node represents room and every edge represent a connection between rooms

Related Work 35

In analogy to the real world, the user interface can be consid-ered as a blank piece of paper where the architect sketches his ini-tial ideas for the building. In a multi-touch environment, gesturesand pen-input [50] are recognized, making it possible to work ina familiar and intuitive manner. In Fig. 7 the user draws a rectanglewithout specifying in advance which kind of entity he is lookingfor, such as a kitchen. The room type is specified by handwrittenannotations.

A first approach for the interpretation of the sketch was realizedin two phases. During the sketching phase the Vision Objects ShapeRecognizer API2 is applied, streaming data from the stylus to extractprimitive geometric structures. The connection types are inferred

using simple geometric analysis which checks in which rectangle aline starts and ends, whether two denoting an access relationship orone denoting an adjacent relationship. The type of drawn entity orrelationship is currently defined by the user. When the user triggersthe search, it will extract a query graph Q from the sketched visualquery. Once the query graph Q is available, the proposed retrievalalgorithm searches for similar reference examples. In Fig. 7 we cansee (a) a search query being sketched, (b) the identified room, and(c) the function and the handwritten functional description. To sum-marize, the semantics of the visual query language (Fig. 8) are:

! Name represent description of structural entities (a).! Rectangles represent structural entities (b).! Single lines indicate adjacent relationship of structural entities

(c).

IfcSpace

IfcRelSpaceBoundary

IfcWallStandardCase

IfcWall

(ABS)IfcBuildingElement

(IfcRelSpaceBoundary.Relating Space)(INV) BoundedBy S[0:?]

(ABS)IfcElement

(IfcRelSpaceBoundary.RelatedBuildingElement)

(INV) ProvidesBoundaries S[0:?]

IfcWallStandardCase

IfcWall


(ABS)IfcElement

(ABS)IfcFeatureElement

Subtraction

IfcOpeningElement

IfcRelVoidsElement

(IfcRelVoidsElement.RelatedOpeningElement)(INV) VoidsElements

(IfcRelVoidsElement.RelatedBuildingElement)(INV) BoundedBy S[0:?]

IfcOpeningElement

IfcDoor

(ABS)IfcElement

IfcRelFillsElement


(INV) FillsVoids S[0:1]

(IfcRelFillsElement.RelatingOpeningElement)(INV) HasFillings S[0:?]

(IfcRelFillsElement.RelatingBuildingElement)

(a)

(b)

(c)

Fig. 5. IFC class diagram (Express-G) describing entities and relations for the graph extraction. Figure (a) depicts adjacency and figures (b) and (c) accessibility.

2 http://www.visionobjects.com/en/myscript/software-development-kits/myscript-shape/: Last accessed 01/10/2013.

418 C. Langenhan et al. / Advanced Engineering Informatics 27 (2013) 413–426

Figure 5.2: IFC entities describing structural relationships[LWL+13]

Related Work 36

5.2 Ifc BIMs and Security

5.2.1 Penetration Testing

The publication we are focusing on here is: “Breaking into BIM: Performing static and

dynamic security analysis with the aid of BIM” [PTTW14].

In this paper the authors expose a proof of concept security simulation tool designed to

assess the physical security of a building by applying known security modelling methods

and heuristics to the information contained within a Building Information Model (BIM).

As in work presented in the previous section, one of the preliminary task to compute is

the extraction of the graph from a BIM IFC file; the approach adopted by the authors

to achieve that result is the same. Also in this work, without focusing too much on the

details, the general idea of the graph is the same as in the previous work: nodes for

rooms and edges for their mutual connections. On of the main difference in respect of

the previous work is the granularity: much more details are retrieved in the IFC file since

the security analysis conducted by their tool are very accurate and so also very expensive

in term of information.

Once the BIM model is translated into a graph two kind of security analysis are con-

ducted: a static and a dynamic one. Both this analysis check the capacity of the building

to resist against penetration from intruders, the static analysis simulate the intrusion just

once and provides feedback about the outcome; the dynamic one simulates two teams

-BLUE and RED teams- respectively defending and attacking the building to assess.

Every member of the attacker team, in the dynamic analysis simulation, is given a tool

and can use it to break into the building, members of the defending team play the part

of constructors and can improve the structure of the building. In the dynamic analysis

the attack against the building is simulated several times and after every attack the blue

team try to improve the security of the building.

At the end of the simulations feedback is prompted to the user that can in this way

discover some potentially weak zones of the assessed construction.

5.2.2 Placing CCTV

Chen et al. [24] consider the problem of helping security administrators configure the

CCTVs available in a physical space efficiently, i.e. avoiding overlapping of CCTVs

coverage. The authors propose a simulation technique to detect which objects and parts

of the physical space are covered when CCTV cameras are placed at predefined locations

and have a specific focal length. The authors adopt the BIM standard to represent the

Related Work 37

physical space (building), CCTV cameras and their placement inside the building areas.

The simulation technique was implemented as a Revit (BIM commercial software) plugin

that improves the simulation of the camera view natively supported by Revit in a way

that better reflects the value of the focal length of the cameras. However, although this

simulation technique can help security administrators tune the CCTV cameras’ focal

length to improve the coverage of the physical space, it does not suggest an optimal

placement of cameras within a building.

5.2.3 Intrusion detection

Rafiee [27] aims to detect intrusions of malicious agents in a physical area by identifying

mismatches between the information provided by Ultra Wide Band Real-time Location

Systems (similar to RFID but more accurate and resistant to noise) and the video record-

ings from the CCTV cameras. In particular, the author uses a BIM model to represent

the building under surveillance; UWB cards are adopted to trace the location of agents

and cameras on the BIM model. The video recordings from the cameras are used to

compute the location of actors on the map. If the position of an agent on the BIM model

does not match the information provided by the UWB cards, an intrusions is detected.

Note that BIM provides a representation of the physical spaces that is accurate enough to

map sensor-measured locations to real-world coordinates and reject noisy data resulting

in false intrusion alerts.

5.2.4 Access Control

In his PhD thesis, Nimalaprakasan [SRD+12] proposes a building information modeling

approach for facilitating the definition of access control policies in critical infrastructures,

such as smart building environments. The author is interested in identifying access

Figure 5.3: BIM to graph transformation. [PTTW14]

Related Work 38

control policies that do not only take into account normal pathways, such as corridors,

stairways and lifts, but also indirect pathways such as ceiling spaces, partition walls,

and ventilation ducts. The author proposes a new policy language extension to XACML

(BIM-XACML), which includes BIM specific data types and functions based on the IFC

specification. This policy language is used to express access control conditions that

involve reachability relationships that can be inferred from the model of the building. In

particular, the author derives a graph from the building in which each node is a room

and each edge is a door; this graph can be used – in combination with policies – to derive

possible paths in which individuals roaming in the building can reach valuable assets.

5.3 Physical Security Assessment

The software presented in this section aim to evaluate the physical security of a building,

different products try to achieve this goal via different approaches to the problem. One

type of tools (such as AVERT) runs simulations on a 3D model of the building to detect

weack points, another type of tools (like VASST) perform evaluation via “checklist” that

is a set of predefined checks to discover potential faults in the interested system.

AVERT2

AVERT is an attack simulation based software that enables four-step risk management

process:

Characterize The AVERT solution begins by characterizing the facility and its security

environment. A detailed 3D model is created that includes facilities, terrain, site

layout, detection and delay systems, and response force.

Industry standard 3D modeling geometry allows for interoperability with other

3D and 2D modeling tools such as Autodesk InfraWorks, Google Sketch-Up and

AutoCAD. Interview based wizards guides user to input concept of operations

and adversary tactics. Drag and drop functionally allows user to select delay and

detection technologies from a library of 50,000 systems.

Synthesize Once the model is complete, AVERT can simulate natural hazards, man-

made security threats and other operational disruptions that are costly both finan-

cially and politically.2http://www.arescorporation.com/software/avert

Related Work 39

Analyze Results of the simulations are represented in 3D model attack paths and in-

tensity maps as well as through detection, interruption, and neutralization graphs

to illuminate all types of vulnerabilities. Attack paths show all possible ways an

adversary can penetrate a facility and defeat a security system. Charts and graphs

depict what systems are detecting, responding, and mitigating vulnerabilities al-

lowing you to understand what systems are critical to your facilities output

Optimize Due to AVERT’s exhaustive scenarios and the ability to alter and rerun

simulations, users can continually assessing all possible risks and optimizing his

security posture and budget to meet changing threat profiles.

AVERT performs security assessment by simulating attacks to the interested building,

with an high level approach that is similar to the one presented in section 5.2.1 of this

chapter. The analogies with our tool are given by: the possibility to import a map from

well known standards format and the possibility to check the imported model against

security threats. The main differences, apart from the grade of maturity of the software,

are: the possibility of checking security in design phase that is not in the aims of AVERT

and the consideration of cyber-phisical threats ignored by AVERT that focuses more in

physical security.

Figure 5.4: An extract of the Avert Brochure. Avert is a Physical Security Assessmentsoftware

Asvaco3

Asvaco enables the redaction of assessment surveys for different purposes: for critical

infrastructure customers, for maritime security, for special events, for safety of school

systems etc. The process of assessment of this tool is structured in four steps:3http://www.asvaco.net

Related Work 40

Development of Question Asvaco works with relevant industry subject matter ex-

perts (SME) to develop necessary questions to guide the automated collection

and creation of content/data necessary to do particular assessments. Easy to

use “yes/no” and “multiple choice” questions are developed and put into Asvaco

Content Module.

Collection of Data Assessors plug in appropriate Content Module to the Asvaco En-

gine, and then collect data, including pictures, video, 3D GIS ( Geographic Infor-

mation System), by answering questions from all necessary sources including the

field, the web, and other sources as missions require.

Analysis of Data Collected raw data is analyzed and converted by the Asvaco Engine

into either completed assessments and/or actionable intelligence for Subject Matter

Expert’s instructions and formulas contained in Content Modules.

Creation of Reports or Presentations Reports are available in a particular viewer

that allows multi media functionality, including 3D GIS (Google earth or Sky-

line) with hot spots, video, audio, spherical 360 video, text to speech, pdf, word

documents etc.

Asvaco is one of the cases in which the customer buys not only a COTS4 software but

also a service. Actually the added value provided by Asvaco lays also in the experience

of SME who collaborates in the analysis of data. This kind of approach is valuable and

probably is the best choice in some context, but represent exactly what my research

group wanted to avoid by design from the first works on security: the human component

in the decision process.

VASST

Vulnerability Assessment Security Survey Tool(VASST) is a second example of sotware

that perform the evaluation of security via surveys. The assessment process is similar

to the Asvaco ones and is composed by: Interview, Generation of Questions, Analysis,

Reporting. Differently from Asvaco, VASST relies less on sector expert but embed part

of their specific knowledge and has the possibility to learn if used of facility of the same

type.4Commercial Off The Shelf

Related Work 41

5.4 Physical Security Information Managing

Physical Security Information Management (PSIM) is a category of software that pro-

vides a platform and applications created by middleware developers, designed to inte-

grate multiple unconnected security applications and devices and control them through

one comprehensive user interface. It collects and correlates events from existing disparate

security devices and information systems (video, access control, sensors, analytics, net-

works, building systems, etc.) to empower personnel to identify and proactively resolve

situations5.

C46

C4 is a server-based building security information system. Its open architecture allows for

seamless control of security subsystems and devices by many manufacturers. The ability

to integrate existing subsystems is claimed to provide a quick return of investment by

simplifying security workflows and decreasing operating costs. Multi-user environment

improves security management by providing the right information to the right agents.

VidSys7

The VidSys platform continuously fuses and correlates vast amounts of data gathered

from any number of virtually any type, brand or generation of physical security system

or sensor, as well as from networked management applications.

VidSys in composed by five modules:

Collection The PSIM software collects data from a multitude of disparate security

devices or systems.

Analysis The system analyzes and correlates the data, events and alarms to identify

and prioritize situations that must be addressed.

Verification PSIM software presents the relevant situation information in a quick and

easily-digestible format for an operator to verify the situation.

Resolution The system provides step-by-step instructions to resolve the situation, based

on the customer’s operating procedures and policies.5http://en.wikipedia.org/wiki/Physical_security_information_management6https://www.c4portal.com/Home.aspx7http://www.vidsys.com/products/vidsys-psim/

http://en.wikipedia.org/wiki/Physical_security_information_management

Related Work 42

Reporting The PSIM software tracks all the information and actions taken for compli-

ance reporting, training or in-depth investigative analysis.

VidSys Software VidSys provides a transformational Physical Security Information Management (PSIM) software platform used to run operations centers for public sector agencies and leading enterprise organizations globally. The platform continuously fuses and instantly correlates vast amounts of data gathered from any number or virtually any type, brand or generation of physical security system or sensor, as well as from networked management applications.

The result is actionable intelligence that empowers decision makers from a single organization or multiple entities – however geographically dispersed – to collaborate in real time. By leveraging mobile devices, the software also provides instant situational awareness and mission-critical intelligence to first responders, senior executives or other authorized parties.

How It Works

Why VidSys? • Commercial-off-the-shelf (COTS) solution• Open architecture – integrates any system or

product• Rapidly deployable, browser-based client• Meets US federal information assurance

requirements • Delivered by experienced team of security and

technology experts

Figure 5.5: Vidsys Open PSIM Platform. Vidsys is an example of PSIM software

Part III

Design and Implementation of

MaraudersWare

43

Requirement Analysis

6.1 Introduction and Starting Point

In the second chapter of this thesis (See 2) we presented the notion of Topology Aware

Adaptive Security and we cited the paper Engineering Topology Aware Adaptive Se-

curity: Preventing Requirements Violations at Runtime. That work has further been

improved keeping into account digital connections and the interplay between physical

and cyber-physical world [Tsi15].

Figure 6.1: Mape Loop as proposed in the [Tsi15] (graphically adapted)

Adaptive security is achieved by implementing the activities of the MAPE (Monitoring,

Analysis, Planning and Execution) loop (see Figure 6.1). Events generated from the

cyber and physical space indicate the execution of agents’ actions.

44

Requirement Analysis 45

During monitoring, events indicating the execution of agents’ actions are received. Dur-

ing speculative threat analysis, future configurations of the topology of the cyber and

physical space that can be achieved when agents perform actions are looked ahead up

to a certain number of steps. Violations of security requirements that can arise from fu-

ture topological configurations are subsequently identified through model checking. The

analysis requires as input the updated model of the cyber and physical space and the

security requirements. After analysis terminates, a set of action execution traces leading

to violations is generated. Action execution traces leading to violations are used during

planning to determine an adaptation strategy aiming to prevent future violations of se-

curity requirements. An adaptation strategy can forbid the execution of some actions

that lead to a violation or can enforce additional actions to restore a violated security

requirement. Selection among more than one actions that can be enforced depends on

their cost which is predetermined by the security software engineer. During execution,

the adaptation strategy is recognised and applied on the real cyber physical system. This

activity receives as input the events indicating the execution of agents’ actions, identifies

when a specific state in the adaptation strategy is reached, and enforces an adaptation

action if necessary [Tsi15].

6.2 Vision

Our main practical contribution to engineering Topology Aware Adaptive Security has

been adding a new module: particularly the one we have called MaraudersWare. Our

module should seamlessly interact inside the MAPE loop The aim of this module is to

provide a Graphical User Interface for security that can be used both by security admin-

istrators or by architects or designers in the early phases of projecting.

Administrators will be able to have a clear and schematic view of the situation inside

the building in terms of assets and agents positions, and if necessary they will be able

to receive notifications in advance about possible security violations.

Designers will be able to draw a sketch of the building, to define security policies (proba-

bly with the help of security engineers involved in the building project), and then to get

feedback from the tool about possible security violations against the defined sketch and

the defined policies. Since when we were designing the requirements for MaraudersWare

the Analysis tool was already developed and it already allowed the user to define secu-

rity requirements, we thought that there was no strong need for our prototype to allow

the definition of security requirements. We believe that it will be possible to develop

something in this direction and we explore this idea in the Conclusion and Future Work


chapter.

As shown in the previous section the tool should be able to dialogue with the Monitoring

and the Analysis modules. It should receive data about the changes in the map topology

(e.g. agents moving from a room to another) from the Monitoring module and it should

send data about the state of the map topology to the analysis module. Our software can

also interface with the security administrator showing him, in real time, the changes in

the map topology. In fact it has to graphically display the movement of the agents and

objects as well as the state of the cyber-physical connections. The Analysis module use

heuristics to reduce the number of states it has to look-ahead, some of this heuristics can

be more effective if Access Control policies are considered. Evaluating these policies the

Analysis module can avoid to consider states of the system that are unreachable because

physically denied. With this rationale we have decided to allow users to define (in a very

basic and simplified way) access control policies.

Figure 6.2: MAPE Loop interfacing with and MaraudersWare

6.2.1 Supporting BIM

In the beginning of our work we decided to investigate more about representing topologies

and formally describing buildings. Our research in this direction have begun wondering

how experts in the field of constructions handle the information about their projects and


more in general what is the “state of the art” in that field. After some research we have

found that BIM approach is the de-facto standard in AEC community, in chapter 3 we

talked the BIM and in particular we have highlighted its impact on the business all over

the world.

Every user of MaraudersWare has to draw a map of the building he wants to have

analyzed, in addition to resources and agents contained; this task can be tedious and so

our idea was to try to get it lighter: namely we give the user the possibility to import

the floor plans contained in BIM IFC file, as well as some resources contained inside the

rooms. We have made some hypoteses about the assets drawable from the BIM model

and also about the rooms structure and so on, that are depicted in chapter 9.

Figure 6.3: BIM Files can be imported, from them topology is discovered and inter-nally represented in MaraudersWare

6.3 Functional Requirements

One of the main goals of MaraudersWare is to provide an environment in which security

administrators can manage some aspects of physical-security and cyber-security. Namely


using our software the security administrator will able to:

• Import from an IFC file the structure of a building as well as some particular

objects contained inside obtaining in this way a map of the building (See 9 for

some limitations about the objects)

• Add, move, delete objects from the map of the building.

• Add, edit or delete access control policies that in some way can predicate on agents

and assets inside the buildings.

• Edit some security-relevant attributes of the objects.

• Define the status of some objects (Like PCs or Printers) that can contain files,

namely he will be able to specify which files are contained and some security rele-

vant meta information for each file

• Define new domain specific objects with customized sets of attributes

• Define and edit connections between objects (e.g. He should be able to add a wi-fi

connection between two PC objects)

• Define containment relations between objects, this relation can, for instance, reflect

the ownership of objects by agents.

• See the real-time position of agents and assets inside the building

• Get informed by the software of sequence of actions leading to a violation of security

requirements.

As we introduces, the other stakeholders of our product are designers and architects in

the early steps of the project. Their requirements are generally speaking similar to the

security administrator ones, with the substantial difference that they should be able to

redefine the structure of the building, namely the should be enabled to:

• Add, edit, delete walls

• Add or delete rooms

• Edit shape of rooms

The other important difference in their use of the program is that they do not need

a real time visualization of the state of resources. Designer should be able to ask the

program to perform a security assessment of their sketched work and getting feedback


from it. Namely this security assessment can consist of a sequence of system states that

can be realistically materialized one after another and lead to security violation. Such a

sequence may not be found by the analysis tool and this is surely something good enough

but off course it does not prove the impossibility of violations to occur.

6.4 Use cases

Here we present a list and explanation of the use cases of the tool, we show an UML use

case diagram which should give an intuitive view of the software functionality.

Manipulate Security Objects User can perform basic operations on objects.

Define new Customized Objects User can define new objects, but he needs. to pro-

vide a 3D representation in order to allow MaraudersWare to correctly display

them on the map.

Define Connections Between Objects Some kind of objects can connect to each

other, for instance PC and Printer can be connected, the intuitive menaning of

connection can be, for instance, that they belong to the same netwok.

Define Containment Relationships Between Objects Containment relation can be

useful to describe possession, this can be important for example for modelling users

with cell-phones1.

Define Access Control Policies User is allowed to define access control policies in a

simplified and basic way, since MaraudersWare is a proof of concept and not a

commercial product, already in requirement phase we have decided not spend too

much effort in the Access Control Policy definition that in development phase is

minimal.

Import IFC File User can import the map of a building from an IFC file.

Edit Building Structure Designers can, off course, edit the structure of the building

by manipulating walls and rooms, they can perform basic operation on them like

changing their position or size, moving or deleting them.

Ask Security Validation Designer can check their scratch of work against policy rules

that have to be previously defined through the Analysis module interface.

1In the implementation of MaraudersWare we do not provide cell-phones as “first class” 4objects butthey can be defined


Figure 6.4: Use cases

6.5 Security Relevant Objects

As we discussed our approach to security is topology aware so it is important model

spatial relationships between rooms but also resources inside them.

It is well known that every model describes some aspects of reality and omits other;

in this work we generically speak about “assets” contained somewhere, but since in our

goals there is the development of a tool that is something concretely realized, during

our requirement study we had to face the problem of defining which particular types of

assets we wanted to model (and as a consequence what omit).

The decision of which resources are security relevant and so which assets to model is,

for its nature, subjective and so there cannot exist an optimum choice. To identify a


list of “interesting” objects to model in our tool we have reviewed several publications

in the field of security and we have asked feedback to businesses collaborating with the

LERO department. From our effort we derived a list of entities to keep in account in the

analysis. We present them here and we briefly explain the motivations for each entity.

Agent It can be useful representing agents because some of their movements could

trigger preemptive actions to secure resources to be protected.

Light It can be useful knowing whether a room is lighted enough or not because an

attacker could potentially exploit the low visibility in order to steal or harm assets.

For this reason we also decided that the “Light” object have to store the information

about its state of “life”: namely a Light can be On or Off or Broken.

CCTV2 Protection is potentially higher if it is possible to know what is happening

inside a room, in our model we do not intend to model sophisticated concepts like

the visibility cone of the CCTV, we just make the assumption that if a CCTV is

located in a room and it is on, then the rooms is controlled.

HVAC3 In some particular rooms can be critical to know the temperature of the air,

this can be true for example in server rooms. Temperature must be an attribute

of this object.

PC It can be necessary modelling PCs because some preemptive actions can be triggered

when documents protected by NDA are opened and visualized on PC screen: if

people are co-located with the PC they can view the PC screen and potentially

steal information.

Printer Motivations for modelling are similar to the PC ones, the obvious difference is

that people can read from documents in phase of printing instead that from the

screen.

6.6 Communication Between Modules

As shown in Figure 6.2 different modules of the system continuously exchange information

about the system state. By means of technologies such as RFID4 it is possible to associate

tags to objects or agents in the system and consequently to know, with a certain level of

accuracy, their location inside the interested environment. The Monitoring module can

receive data from resources inside the building and communicate them to the Analysis

Module and to MaraudersWare which in turn shows to the System Administrator the4Radio Frequency Identifiers


updated state of affairs; in Figure 6.5 we show a representation of this concept. When

the Analysis Module detect a possible security violations in future states of the system, it

promptly notify the Planning Module that will elaborate possible countermeasures and

MaraudersWare that informs the Security Administrator of the state of the system and

about the possible threat.

Figure 6.5: Monitoring Module communicates with MaraudersWare

Figure 6.6: Analysis Module communicates with MaraudersWare

6.7 Scenarios

In this section we present two scenarios explaining possible uses of our tool. This scenarios

are maybe too simple and slightly unrealistic but their purpose is just to provide an

example of use of the software.


6.7.1 Designer check Security of his preliminary scratch

Alice is a Designer that works in a big architect studio and has been awarded to provide a

first scratch of a project for a bank. She has used Autodesk Revit to define the structure

of the first floor of the bank, now she wants to perform some security controls on her

project using MaraudersWare. She opens Revit and select the option to export her work

in IFC format, then she open it with MaraudersWare. She adds some objects like CCTVs

and PCs, she draws the “Safe-Room”. Alice wants to place an Object representing a Safe,

in order to get a nicer representation of the state, but this kind of object is not present

from the predefined ones, so she search in the internet for a 3D representation of a

safe, she downloads it and she import it in MaraudersWare. Now she wants to define

some security requirement, even not being an expert Alice can think some basic security

requirements and input them in the Analysis tool. The next step is asking the tool to

perform some analysis for identifying possible security violations, so she press “Analyze”

button in MaraudersWare, she waits some time and eventually the tool prompt her

a sequence of states that can lead to a security violation. Reading this sequence she

understand that there is need to separate more the safe from the others rooms so she

changes some of the structure of the building. She can iterate the aforementioned process

until she reaches an acceptable result.

6.7.2 Security Administrator is informed of Possible Security Violation

Richard is the security administrator of a department of a big and modern company. His

company provides cloud services to thousands of users all over the world and for this

reason hosts a huge number of servers distributed in several server rooms. Richard uses

MaraudersWare to monitor the situation of some spaces, one of them being a server room,

that are under his responsibility. In his department every sensitive object (like CCTV,

Servers etc.) is tagged with an RFID, every person is given an electronic card, and

every door has a sensor and an opening mechanism that allow it to open when electronic

card is used. As additional security measure, doors can receive a signal that remotely

lock or unlock them. MaraudersWare continuously receives data from door sensors and

RFIDs, so in every moment it can hold an updated state of the topology. In the server

room there is a printer that need to be repaired by Mallory: an outsider technician,

one of the security policies of the company states that no outsider may enter the server

rooms without being accompanied. Since Mallory has just arrived, Richard focuses his

attention on the spaces close to her namely: the Corridor in which Mallory is, the Wi-Fi

room and the Server Room that are the only two rooms reachable from the corridor.

Richard can see that in the corridor are located also Bob and Eve. The Analysis module


is aware of the topology and of the Security Requirements and keeps looking ahead to

discover possible violations. When Bob steps into the Wi-Fi room, the Analysis module

looks ahead and detect a violation in one of the possible future states: namely in the

future state in which Bob is in Wi-Fi room and Mallory has stepped in Server Room

(alone). Tha Analysis modules notifies the Planning module that in turn inform the

Execution Module which sends a signal to the door linking the Corridor with the Server

Room in order to lock it, then the security administrator is notified, MaraudersWare

shows it graphically the “state of affair”: informs him that a security violation has been

stopped and shows him the current position of assets and agents. Richard understand

the situation and keeps monitoring the system.

Implementation

7.1 Introduction

In this chapter we are reviewing our implementation of our tool: MaraudersWare, as

said in Requirements chapter, this tool form a fifth component of the MAPE loop inter-

facing with Analysis and Monitoring modules and providing a user interface for security

administrators or designers. In the next session we are briefly describing “Sweet Home

3D”: the open source and free software we started from in our implementation, then, in

Software Architecture we are giving a coarse grained vision of MaraudersWare, while a

more fine grained vision of it is given in the Functionality section.

7.2 SweeHome3d: A starting point

In order to implement the tool described in this chapter, we have started from a free

and open source interior design application: “Sweet Home 3D”. Sweet Home 3D is a

free interior design application that helps user to draw the plan of your house, arrange

furniture on it and visit the results in 3D.1

Figure 7.1: Screenshot of Sweet Home 3D from the developer site: sweethome3d.com

1http://www.sweethome3d.com

55

http://www.sweethome3d.com

Software Architecture 56

7.2.1 User Perspective

The main stakeholders of Sweet Home 3D are people who, for different reasons, want to

project their home interior relying on a nice and handy Graphical User Interface. This

software allows users to:

• Draw walls and set their thickness.

• Draw rooms, assign them meaningful names.

• Place typical interior objects inside the rooms like for instance tables for kitchen,

couch for living rooms and so on.

• Redefine some attributes of objects like colour, rotation, size.

• Import new objects from a 3D representation

• Get a 3D rendering of the defined home.

7.2.2 Developer Perspective

Sweet Home 3D is developed using the Object Oriented approach and written in Java.

It relies on the MVC (Model View Controller) pattern. Like suggested by the program

name, the “home” is the core of the project around which all the software architecture is

built. A Home object maintains references to rooms, walls and furniture contained in the

house. There are two views: the 2D plan of the building and the 3D representation of

it. When an object attribute is modified the views are notified and updated accordingly.

Application core functionality like open, save, or print a project, are implemented inside

the controllers who handle the interplay between Model and View, like proposed in the

MVC pattern.

7.3 Architecture

We called our prototype MaraudersWare after its (unaware) “predecessor” Sweet Home

3D. Its architecture, omitting some minor implementative details, can be seen as four

components. We will now briefly introduce them and later in this section, we are explor-

ing them more in detail.


• IFC file Importer: takes as input an IFC file 2 and produces as output a Graph

representing the building topology as well as graphical 3D objects representing

topology elements that are displayed in the GUI.

• Topology Graph: right after the IFC importation a graph is generated: a graph

representing the topology of the building (just the physical one because in IFC

format there is no support for modelling digital connections). This graph is auto-

matically kept in sync with the security administrator inputs, so for instance if the

administrator moves an object then the graph is updated accordingly.

• Security Relevant Objects: analyzing the requirements we have derived some ob-

jects that are relevant for security analysis. For each of this object the tool provides

a graphical 3D representation as well as a model-level representation that is trans-

parent to the user but that is useful for exchanging information with Analysis and

Monitoring modules.

• Analysis and Monitoring Integration: in order to communicate with the Analysis

and Monitoring modules we have chosen to adopt the JSON standard. This module

translate the topology graph into JSON to send it as output and performs the

opposite process when receiving JSON in input.

In figure 7.2 it is showed the global architecture of the system and particular emphasis is

given to the flow of information. The core part of the architecture is the Internal Graph

Representation that is the Topology Graph. This graph can be generated starting from

an IFC file or from the graphical view representation of the building, it can be updated

by the Monitoring module.

7.4 Functionality

7.4.1 Topology Graph

A Building Security Graph is an object that stores all the meaningful and analysis-

supporting information, this object sores information about:

• Rooms inside the building (BuildingRoomNode)

• Walls and Doors connecting rooms (BuildingLinkEdge)

• Objects contained in each room (Asset)2Generated with a BIM program


Figure 7.2: Global Architecture of MaraudersWare, communication with Monitoringmodules is showed

• Digital connections between objects (CyberLinkEdge)

This component represent a multi-graph: a graph with multiple (here two) type of edges.

Each node of this graph is a room (a BuildingRoomNode) and each edge is a simple wall

or a wall that contains a door (every edge is BuildingLinkEdge ). Each node also stores

information about the contained objects (Asset). The graph is further enriched with dig-

ital connections that are links between objects, each link is realized by a CyberLinkEdge.

BuildingSecurityGraph is the central component of the application, it perform the bind-

ing between model objects and view 3D objects. In our implementation this object store

some redundant information (in form of hash-maps) that is used to rapidly update the

state of the graph when agents or assets are moved. In figure 7.4 we show the class

diagram of the components related to Topology Graph. In figure 7.5 is represented the

general idea behind the Building Security Graph: a graph that stores building struc-

ture and cyber-connections. The Security Graph is implemented as singleton and the

singleton instance is available from every class of the project.

7.4.2 IFC file Importer

In figure 7.7 we show the class diagram of some important components used for the

extraction of the topology graph from an IFC file. SecurityExtractor is the abstract class

that outline every object that can generate a BuildingSecurityGraph (the topology graph)

in some way. This graph can be derived from an IFC file, by an IfcSecurityExtractor, or

from the map of the building displayed in the view, by a HomeSecurityExtractor.


Figure 7.3: Simplified Package Diagram of essential components of MaraudersWare

We realize an IFC parser by means of two components: an IFC parsing library (IFC

TOOL Project 3) and an IfcSecurityExtractor object, see 7.6. The library allow to in-

stantiate a specialized java parser object focused on IFC parsing. This object can process

an IFC file and produce in output a collection of java objects that precisely replicate the

structure of the IFC file. This collection potentially consists of thousands of objects

because average IFC files can contain thousands of line and the parser object perform

a one-to-one mapping between the lines in the IFC file (each describing an IFC entity)

and the java objects created. For this reason another step in the parsing is needed:

we process this collection with an IFCFileExtractor object to get a BuildingSecurity-

Graph in which information is represented in compact way. Being a SecurityExtractor

the IFCFileExtractor has to provide a BuildinSecurityGraph, for this reason it traverses

the collection of the java objects mapping the IFC lines in order to retrieve all the useful

for it4 namely: rooms inside the building, walls and doors connecting them and objects3http://www.ifctoolsproject.com4Except for the CyberLinks cause the digital connections, as far as our research discovered, are not

modelled in IFC files


BuildingLinkWall

BuildingLinkWall()getWall()toString()

BuildingLinkEdge

BuildingLinkEdge()getFirstRoom()getSecondRoom()toString()equals()

BuildinLinkWallWithDoor

BuildinLinkWallWithDoor()toString()getDoor()setDoor()

BuildingSecurityGraph

getLinkEdgeList()setLinkEdgeList()getRoomNodeList()setRoomNodeList()getNotLinkingWalls()setNotLinkingWalls()getCyberLinks()setCyberLinkEdgeList()

CyberLinkEdge

CyberLinkEdge()getIdObject1()getIdObject2()setIdObject1()setIdObject2()getName()setName()

BuildingRoomNode

BuildingRoomNode()addObjectContained()getRoomSmart()setId()getObjectsInside()setObjectsInside()removeObject()

Figure 7.4: Class Diagram of Topology Graph

Figure 7.5: Schema of Internal Graph Representation. Cyber-links are representedwith dashed lines


contained inside rooms.

The parsing library we have used allows a one-to-one mapping between java objects and

IFC entities, it can process an IFC file and provide an “IfcModel” object that is a java

representation modelling that file. This model can be queried for all the entities of a

certain type (java class). Since, under reasonable hypothesis (see 3.8.2 in chapter 3)

IfcSpace entities match rooms, it is possible to discover all the rooms of a building just

querying the IfcModel all the IfcSpace entities that it contains.

With this approach the IfcExtractor obtains a list of IfcSpace. The IfcSpace entity stores

several object attributes, specifying several properties two of them being location and

shape of the room. The room location is defined in term of relative coordinates: 3D

cartesian axes (IfcAxis2Placement3D) are recursively nested inside each other starting

from the outside of the building and progressively approaching the room in a hierarchic

structure. The shape of the room is defined by the IfcProductRepresentation, there

are several way in which IFC allow to specify the representation of an object, in our

implementation we assume that rooms are represented by rectangles and namely using

the IfcRectangleProfileDef object.

Every IfcSpace can be queried for the other spaces bounding it (the adjacent rooms)

getting its “BoundedBy” attribute; this object attribute reflect the homonymous IFC ob-

jectified relation that links every space with the spaces sharing a wall with it. Traversing

the BoundedBy attribute it is possible to know every room adjacent to a considered

space and the wall separating them. Inspecting the wall the IfcFileExtractor can under-

stand whether it contains a door or not and so it can create an appropriate instance of

BuildingLinkEdged (see Figure 7.4).

Assets contained inside an IfcSpace can be deduced in a similar way, for this purpose

the ContainsElements relation, attached as an object attribute to every IfcSpace, can

be exploited. This objectified relation binds every room to the contained objects. Every

object is an IfcProduct, and it has a name. We are not interested in any possible furniture

object, but just in what we have called “Security Relevant” objects. The IFC format does

not explicitly consider any of that objects, and so BIM applications when translating

them into IFC use the IfcBuildingElementProxy entity. Since IFC does not explicitly

consider this kind of objects (for example there is not an IfcPrinter entity), we just

rely on the objects names to parse them and so for instance if an IfcProduct is named

“Printer-01” we consider it a printer and we generate a PrinterObject that it will be

modelled as contained in the related IfcSpace.


Figure 7.6: Relationship between HomeSecurityExtractor and IfcSecurityExtractor

IfcSecurityExtractor

IfcSecurityExtractor()getGraph()

HomeSecurityExtractor

HomeSecurityExtractor()getGraph()

SecurityExtractor

SecurityExtractor()getGraph()

SavedConfigurationsLoader

getSweetHomeNameForType()getTypeForSweetHomeName()getObjectAbilities()getMapTypeToFurniture()getPossibleAttributesForObject()getAvailableRoles()getNamesConventions()setObjectAbilityStatus()

SecurityNameAndMap

sweetCatalogToType: Map<String,AssetType>TypeToSweetName: Map<AssetType,String>securityCategoryName: String

SecurityNameAndMap()

BuildingSecurityGraph

getLinkEdgeList()setLinkEdgeList()getRoomNodeList()setRoomNodeList()getNotLinkingWalls()setNotLinkingWalls()getCyberLinks()setCyberLinkEdgeList()

Figure 7.7: Class Diagram of Extractor components, one of them is the IFC Extractor

7.4.3 Security Relevant Objects

From the requirements analysis we derived a list of security relevant objects:

• Actor Object: an agent inside the building

• CCTV Object: a Closed Circuit Television

• Light Object: a light inside the building

• HVAC Object: a Heating, Ventilating, and Air Conditioning inside the building

• PC Object: a Personal Computer or a Computer in general inside the building

• Printer Object: a Printer inside the building


All the material objects of this list (that is all except the Actor Object) have a life

status that states whether the object is ON, OFF, or Broken. Some of this objects, by

default5, can store files and digitally connect to other objects. Every object, by design,

can contain other objects: there is so a recursive tree-structured containment relation

between objects.

This list can be further increased by the security administrator, he can define new cus-

tomized objects: for each new object he can specify whether the object can digitally

connect with other objects, whether the object can store files. For every object the secu-

rity administrator can define new attributes: for instance he can define a new attribute

“temperature”, floating numeric type, for the Light Object.

LifeStatus

AssetType

PCObject

PCObject()

ActorObject

ActorObject()FileHolder

FileHolder()addFile()removeFile()getActiveFiles()setActiveFiles()getActiveFilesStr()getStatusForView()setStatusFromView()iterator()

PrinterObject

PrinterObject()

MaterialObject

MaterialObject()getLifeStatus()setLifeStatus()getStatusForView()setStatusFromView()toString()

FileObject

FileObject()FileObject()FileObject()getActualFile()setActualFile()getSecurityLevel()setSecurityLevel()getDiscloseLevel()setDiscloseLevel()getFileRepresentation()

NonDisclose

SecurityLevel

CCTVObject

CCTVObject()

LightObject

LightObject()

HVACObject

HVACObject()

GeneralFileHolder

GeneralFileHolder()

GeneralMaterialObject

GeneralMaterialObject()

Asset

Asset()getPieceOfForniture()canConnect()getPosition()setPosition()getType()getObjectContained()setObjectContained()addObjectContained()getAttributes()getAbilities()setAbilities()

Figure 7.8: Class Diagram of Security Relevant Objects

7.4.4 Updating the Internal Representation

As we said in the requirements our tool is thought for two different kinds of purposes:

monitoring resources to prevent security violations and supporting the design of secure

spaces. To grant these macro functionality, MaraudersWare relies on an internal repre-

sentation6 of the topology of the building to be protected or designed. An important

difference between this two uses is given by the time constraints. We assumed that when

our tool is used by a security administrator to monitor a space, it is important to update5this is configurable via preference file6As said before, the internal representation is encoded in the Topology Graph object.


the Topology Graph in real time (at least in principle) because it is used in the MAPE

loop which iterations, hopefully, last a very little amount of time. This urgency for an

updated internal representation is not so strong when MaraudersWare is used to validate

drafts against security requirements, in design phase; in effect the Topology Graph needs

to be consistent with the interface view just when the designer asks for a validation.

Our tool can not be aware of the role of its user and, for this reason, it adapts its be-

haviour based on some assumptions. When our software receives the request of moving

a resource (this request can come from the Monitoring module or from the user input)

it assumes that is something occurring in a monitoring context and so it updates the

Topology Graph. Something analogous happens when resources are created or deleted

or when their state is changed. Conversely, when doors, walls or rooms are edited, the

tool assumes that a designer is drawing a draft of its project and so there is no need

to immediately update the Topology Graph. Nevertheless the tool contains a “refresh”

functionality, transparent to the user, that can be activated when the topology has to

be transferred to the Analysis module.

This functionality exploits the HomeSecurityExtractor class that we have mentioned

before in this chapter. MaraudersWare uses the MVC pattern as the software we started

from; for this reason every object displayed in the view (such as agents, printers, CCTVs

etc.) have a corresponding model object. Examples of this objects useful to describe a

space are: Wall, Door, Room, PieceOfForniture; the first three are used to describe the

physical structure of the space while the last describes objects contained inside rooms.

Iterating on this objects the HomeSecurityExtractor can derive a BuildingSecurityGraph.

7.4.5 Digital Connections Creation

Once the user has selected two objects, if the objects are both digitally connectable he

can click on a “connect” button and create a digital link (a “Cyber-Link”) connecting

them. It is possible to specify a name for the connection, this is done keeping in mind

the Bigraph formalism, namely the “link graph” (see chapter 4). Once two objects are

connected a CyberLink is created and the BuildingSecurityGraph is updated accordingly.

From a graphical point of view, in MaraudersWare it is possible to apply a filter on the

visible objects and show/hide the digitally connectable objects like PCs or Printers.

7.4.6 ABAC Policy Definition

In order to support the Analysis module reducing the number of states to look-ahead,

we allow the user to enter some Attribute Based Access Control Policies. Due to time


constraints there is no semantic control on the user input, but we provide an interface

in which the Security Administrator can specify rules, each comprehending:

Agent ID The id of the agent interested by the rule.

Action The action regulated by the policy, for instance open, read, write.

Resource The id of the resource the action is direct for instance the id of a specific PC

or Printer.

Environment A specific location like a room or a date or a time span.

Even if there is no full semantic support for this policies, it is still possible to define, via

textual file, a set of assignable roles and, once selected an agent, define what roles he is

invested. Some predefined roles are: employee, chief, visitor technician.

7.4.7 Analysis Integration

MaraudersWare have to communicate with the Analysis and Monitoring modules. To

do so we define a simple communication protocol. The information exchanged with

MaraudersWare is recapped in table 7.1. The Containment Forest is a set of trees

drew from the Building Security Graph, every root is an asset and its sons are the

contained assets. Every node is decorated with attributes of the asset (including stored

files if needed). The Connection Graph is the set of the CyberLinks. Possible Security

Violations can require a sequence of states because the number of look-ahead states can be

greater then one. Each Security Violation corresponds to an annotated counterexample

obtained by model checking techniques.

From To Information ExchangedMaraudersWare Monitoring Module Containment Forest and Connection GraphMaraudersWare Analysis Module Containment Forest and Connection Graph

Monitoring Module MaraudersWare Containment Forest and Connection Graph

Analysis Module MaraudersWare Possible Security Violations in future states,Solution Proposed

Table 7.1: Information Exchanged with MaraudersWare

We present here the core of the protocol: the State, it describe the Containment Forest

(Agents and Assets) and the Connection Graph (Digital Connections). Possible Security

Violations is a list of State and Solution Proposed is a State.


State {

Agents and Assets : ResourceList ,

Digital Connections : ConnectionList ,

}

[]

ResourceList Resource ,

[ Resource ]

[]

ConnectionList Connection ,

[ Connection ]

Connection graffa

label: String ,

source: String ,

targets: ListOfResourceID

}


Resource {

id: String ,

type: ResourceType ,

roomId: String ,

additionalAttributes: ListofAttributes ,

FilesContained ,

connectable: Boolean

sons ListOfResourceID

}

String ,

ListOfResourceID [ String ]

Figure 7.9: Grammar for protocol for communication between Sweet Home 3D + andMonitoring module

A Demonstration of MaraudersWare

In the last two chapters we gradually introduced MaraudersWare, we explained its pur-

pose and we investigated its architecture and implementation. In this chapter we are

considering a full example that illustrates part of its possible use.

8.1 Demonstration Scenario

To provide an example of possible use of MaraudersWare we consider a simple scenario,

in which a Security Administrator monitors a small but modern building which compre-

hends a corridor, from which is possible to reach a Wi-Fi area and a Server-Room. The

floor plan is illustrated in Figure 8.1. Users in Wi-Fi room can connect to the internet

via wireless network. Server room hosts some valuable assets like servers and printers.

Agents can roam in the building, access to rooms is granted or denied based on a device

installed on every door that enforces Access Control policies, every agent has an elec-

tronic card that grant him the access to the rooms he is allowed to reach, every door can

be locked or unlocked remotely. For this simple scenario we consider a single security

requirement (SR1): outsider agents should always be accompanied in the server room,

with the rational that if they were allowed to be alone they potentially could harm or

steal assets. For the first demo scenario, we consider a visiting technician, Mallory, who

requires access to the server room to repair the printer. If she is unaccompanied, the

security requirement (SR1) is violated. To prevent this security breach several actions

can be performed while Mallory is in the corridor. For example, she can be forbidden

from accessing the server room until another employee (e.g., Bob) has accessed the server

room. [Tsi15] We present here a detailed view of the evolution of the system, the scenario

we show is articulated in four states happening one after another:

Initila State Three agents: Bob, Mallory and Eve are in the corridor.

Second State Bob steps into the Wi-Fi room.

68

A Demonstration 69

Third State The Analysis Module detects a possible security violation and inform Ma-

raudersWare.

Fourth State The Security Administrator applies the solution proposed by Analysis

Module.

Figure 8.1: Floorplan of Demo Building

Initial State

We can imagine that before the initial state the MAPE loop has been running and so

every module has a synchronized view of the topology. In listing 8.1 it is showed the

representation1 of the topology that the Monitoring Module, that receives information

from the real system (for instance by means of RFIDs), sends to MaraudersWare.

Agents and Assets : [

{

"id": "eve",

"type": "ACTOR",

"roomId": "Corridor",

"additionalAttributes": [],

"connectable": "true",

"contains": []

},

{

"id": "pc -2",

"type": "PC",

"roomId": "Server Room",



"contains": []

},

{

"id": "printer -0",

"type": "PRINTER",




"contains": []

},

{

"id": "mallory",

"type": "ACTOR",




"contains": []

},

{

"id": "pc -0",

"type": "PC",



1In the considered scenario digital connections does not play any role and so we omit its representationin the information exchanged between modules, in this State and in the next

A Demonstration 70

Figure 8.2: Initial state of the Building Topology displayed by MaraudersWare


"contains": []

},

{

"id": "pc -1",

"type": "PC",




"contains": []

},

{

"id": "bob",

"type": "ACTOR",




"contains": []

}

]

Listing 8.1: Containment Graph ofAgents and Assets of initial state rep-resented in JSON format. This dataare passed fromMonitoring Module to

MaraudersWare

A Demonstration 71

Second State

Bob uses his electronic card to enter the Wi-Fi room, the Monitoring Module is in-

formed: it updates its internal representation and inform MaraudersWare accordingly.

The information passed for this purpose is showed in listing 8.2.

Figure 8.3: Topology of the Building in the second state


{

"id": "bob",

"type": "ACTOR",

"roomId": "Wifi Room",



"contains": []

},

{

"id": "printer -0",

"type": "PRINTER",




"contains": []

},

{

"id": "eve",

"type": "ACTOR",




"contains": []

},

{

"id": "pc -2",

"type": "PC",




"contains": []

},

{

"id": "mallory",

A Demonstration 72

"type": "ACTOR",




"contains": []

},

{

"id": "pc -0",

"type": "PC",




"contains": []

},

{

"id": "pc -1",

"type": "PC",




"contains": []

}

]

Listing 8.2: Containment Graph ofAgents and Assets of first state rep-resented in JSON format. This dataare passed fromMonitoring Module to

MaraudersWare

Violation State

When Bob enters the room the Analysis Module is informed and performs the look-

ahead of the possible next states2, for each possible future state it checks the security

requirements (in our scenario just SR1). By doing so the Analysis Module discover a

“Violation State” so it informs the Planning Module that in turn informs the Execution

Module who locks the door of the Server Room. MaraudersWare is notified as well

(see 8.3) and shows the Security Administrator the discovered security violation.


{

"id": "bob",

"type": "ACTOR",




"contains": []

},

{

"id": "pc -1",

"type": "PC",




"contains": []

},

{

"id": "printer -0",

"type": "PRINTER",




"contains": []

},

{

"id": "eve",

"type": "ACTOR",




"contains": []

},

{

"id": "pc -0",

"type": "PC",




"contains": []

},

{

2To prevent the explosion of the number of states to look-ahead heuristics are adopted, and the depthof the states speculation can be set by the user

A Demonstration 73

Figure 8.4: Floorplan of Demo Building in Violation State

"id": "pc -2",

"type": "PC",




"contains": []

},

{

"id": "mallory",

"type": "ACTOR",




"contains": []

}

]

Listing 8.3: Containment Graph ofAgents and Assets of violation staterepresented in JSON format. Thisdata are passed from Analysis Mod-

ule to MaraudersWare

Solution State

Not only the Analysis Module can inform the rest of the MAPE components of the

possible security violation, but it is also able to propose a “Solution State” preventing

the violation to occur. Namely in our scenario the proposed solution is asking Eve to enter

Server Room, the proposed solution is exposed in listing 8.4. The Security Administrator

asks Eve to enter the Server Room, in this way SR1 is granted and no security violation

take place. The topology of the Solution State is then represented by MaraudersWare

(see Figure 8.5)

A Demonstration 74

Figure 8.5: Floorplan of Demo Building in Solution State


{

"id": "bob",

"type": "ACTOR",




"contains": []

},

{

"id": "pc -1",

"type": "PC",




"contains": []

},

{

"id": "printer -0",

"type": "PRINTER",




"contains": []

},

{

"id": "eve",

"type": "ACTOR",




"contains": []

},

{

"id": "pc -0",

"type": "PC",




"contains": []

},

{

"id": "pc -2",

"type": "PC",




"contains": []

},

{

A Demonstration 75

"id": "mallory",

"type": "ACTOR",




"contains": []

}

]

Listing 8.4: Containment Graphof Agents and Assets of the solu-tion state represented in JSON for-mat. The solution state is proposedby the Analysis Module. This dataare passed from Analys to Marauder-

sWare

Evaluation

In this chapter we try to evaluate our work, in the “Business Feedback” section we talk

about the impression our work give to UTC business unit, in “Limitations” section we

expose some of the limitations of our work.

9.1 Practitioners Feedback

As we said in the “Introduction” chapter, this thesis has been developed in the context of

a broader project. The part of our research group that refers to LERO research center,

has been working in collaboration with UTRC. During our collaboration in LERO we

had the opportunity to show MaraudersWare to the business unit of UTRC, our tool can

support some security analysis that have been considered relevant by this business unit.

9.2 Limitations

9.2.1 Rectangular Rooms

In chapter 7 we have explained, in principle, how the IFCFileExtractor works and we have

highlighted a strong assumption we have made about rooms: their shape is rectangular

and it is represented by an IfcRectangleProfileDef object. IFC standard allows several

ways to define rooms shape, for example specifying the ordered set of points that defines

the perimeter of the shape; another way of specifying a room shape is listing the various

faces of the solid identified by the room itself.

9.2.2 Name conventions

Another limitation involved in the parsing process is given by the fact that we rely on

names to parse IfcProduct entities, this limitation is more difficult then the previous to

76

Evaluation 77

overcome because the IFC format does not provide a rich ontology when dealing with

security relevant objects. We can advocate that is reasonable to assume that BIM users,

like architects, probably give meaningful to objects since BIM software allow them to do

so, but still nothing forbids that non-meaningful names are given to assets inside a BIM

project.

9.2.3 Single Floor Buildings

When implementing MaraudersWare we have tested the Ifc Parser just on IFC files

of simple buildings with just one floor, in chapter 7 we have described how we get

the list of all the rooms of the building and namely querying an “IfcModel” for all the

IfcSpace entities contained inside the building. It is clear that if the building has two

or more floors, the rooms of the two or more floors are returned by the IfcModel. It

is straightforward understating the floor of a room querying the IfcSpace entity, the

problem is that the connections in the Topology Graph should be revised to consider

multi-floor buildings and so, for instance, to keep into account other building entities

such as stairs and elevators as well.

Part IV

Conclusion and Future Work

78

Conclusion and Future Work

10.1 Conclusion

The main theoretical contribution proposed in this thesis is the idea of exploiting the BIM

technology, state of the art in the AEC community, for providing topology information

to be used by Adaptive Security Systems. Although BIM has been used in literature in

the context of security, to the best of our knowledge, it has been never used with such

systems. Moreover, we have identified some security aspects that, we believe, are worthy

to be considered when modelling a topology that will be used for security analysis.

The problem we started from was the lack of a formal approach to the design and

protection of cyber-physical spaces. In our research we have investigated the state of

the art in the AEC/FM community to understand what field experts were using and

we discovered the BIM technology. After this finding the next natural step has been

reviewing what has been done in terms of collaboration between BIM and Security. We

have not found any use with BIM and cyber-security, but instead we have found some

very interesting works about BIM and physical security.

We also wanted to understand the state of the art in the field of commercial applications

to handle physical security, for this reason we have reviewed some software and, from

what we have found, we have reached the conclusion that there is tool that can allow a

designer to project a building and check some security properties, analogously there are

tools supporting security administrators to handle physical security, but none to handle

cyber-security and their interplay.

In this thesis we outlined MaraudersWare: a proof of concept tool our research group

has developed. It allows designers to validate their preliminary drafts against some

security requirements they can specify. Moreover, it can support security administrators

to monitor a space: to understand the positions of agents and assets and to discover in

advance possible security violations and to prevent them.

79

Conclusion and Future Work 80

10.2 Future Work

The tool we developed is a proof of concept and much work has still to be done to make

it grow and production ready. In chapter 9 we have seen some current limitations of our

work, a starting point for future work could be trying to, at least partially, overcome

these limitations.

Rectangular Room limitation can be solved expanding the IfcFileExtractor, in partic-

ular giving it the ability of distinguish among the different types of shape in which

rooms can be represented.

Name conventions limitation is harder to solve because IFC format have actually no

well defined semantic for some kind of security relevant objects. What is possible

to do is asking buildingSMART company to extend the standard in order to keep

in account some type of objects and integrate them in the IFC schema. Modifying

a standard is something that requires a great amount of time, but in principle is

feasible.

Single Floor Buildings limitation can be solved investigating more the IFC model,

the Topology Graph should be updated because new kinds of connections should

be considered like elevators and stairs.

Overcoming limitations is not the only direction in which future works can proceed: in the

current state, Security Requirements are textually specified in the Analysis module. It

could be interesting integrating the Graphical User Interface of MaraudersWare with the

Analysis module in order to allow user to graphically specify the Security Requirements.

Another interesting possibility would be giving MaraudersWare more awareness about

Attribute Based Access Control, and provide a richer support to policy definition, there

is something done in the definition of roles because it is possible specifying the roles of

an agent, but nothing has been done to define what context is.

Bibliography

[AK] Filip Stubkjær Adamsen and Søren Houbak Kristiansen. Middleware for

mobile 3d building rendering.

[ANML08] Salman Azhar, Abid Nadeem, Johnny YNMok, and Brian HY Leung. Build-

ing information modeling (bim): A new paradigm for visual interactive mod-

eling and simulation for construction projects. In Proc., First International

Conference on Construction in Developing Countries, pages 435–446, 2008.

[Bay10] J. Bayuk. System security engineering: Final technical report serc-2010-tr-

005, 2010.

[Bay11] Jennifer L Bayuk. Alternative security metrics. In Information Technology:

New Generations (ITNG), 2011 Eighth International Conference on, pages

943–946. IEEE, 2011.

[Boa97] Construction Industry Board. Briefing the team: A guide to better briefing

for clients. Thomas Telford, 1997.

[Boe13] Roeland Boeters. Automatic enhancement of CityGML LoD2 models with

interiors and its usability for net internal area determination. PhD thesis,

TU Delft, Delft University of Technology, 2013.

[Bur06] David S Burggraf. Geography markup language. Data Science Journal,

5:178–204, 2006.

[BZMK09] Nigel Baker, Madiha Zafar, Boris Moltchanov, and Michael Knappmeyer.

Context-aware systems and implications for future internet. In Future In-

ternet Assembly, pages 335–344, 2009.

[Cam07] Dace A Campbell. Building information modeling: the web3d application

for aec. In Proceedings of the twelfth international conference on 3D web

technology, pages 173–176. ACM, 2007.

81

Bibliography 82

[CD14] Jack CP Cheng and Moumita Das. A bim-based web service framework for

green building energy simulation and code checking, 2014.

[CdLG+09] BettyH.C. Cheng, Rogério de Lemos, Holger Giese, Paola Inverardi, Jeff

Magee, Jesper Andersson, Basil Becker, Nelly Bencomo, Yuriy Brun, Bojan

Cukic, Giovanna Di Marzo Serugendo, Schahram Dustdar, Anthony Finkel-

stein, Cristina Gacek, Kurt Geihs, Vincenzo Grassi, Gabor Karsai, HolgerM.

Kienle, Jeff Kramer, Marin Litoiu, Sam Malek, Raffaela Mirandola, Hau-

siA. Müller, Sooyong Park, Mary Shaw, Matthias Tichy, Massimo Tivoli,

Danny Weyns, and Jon Whittle. Software engineering for self-adaptive sys-

tems: A research roadmap. In BettyH.C. Cheng, Rogério de Lemos, Holger

Giese, Paola Inverardi, and Jeff Magee, editors, Software Engineering for

Self-Adaptive Systems, volume 5525 of Lecture Notes in Computer Science,

pages 1–26. Springer Berlin Heidelberg, 2009.

[CG98] Luca Cardelli and Andrew D. Gordon. Mobile ambients. In In Proceedings

of POPL’98. ACM Press, 1998.

[Con14] McGRAW Hill Construction. The business value of bim for construction

in major global markets: How contractors around the world are driving

innovations with building information modelling. Smart MarketReport, 2014.

[Dey01] Anind K Dey. Understanding and using context. Personal and ubiquitous

computing, 5(1):4–7, 2001.

[Dij72] Edsger W. Dijkstra. Structured programming. chapter Chapter I: Notes on

Structured Programming, pages 1–82. Academic Press Ltd., London, UK,

UK, 1972.

[DNFP98] Rocco De Nicola, Gian Luigi Ferrari, and Rosario Pugliese. Klaim: A kernel

language for agents interaction and mobility. Software Engineering, IEEE

Transactions on, 24(5):315–330, 1998.

[DPH10] Trajce Dimkov, Wolter Pieters, and Pieter Hartel. Portunes: representing

attack scenarios spanning through the physical, digital and social domain.

In Automated Reasoning for Security Protocol Analysis and Issues in the

Theory of Security, pages 112–129. Springer, 2010.

[DPS+05] J Depoy, J Phelan, P Sholander, B Smith, GB Varnado, and G Wyss. Risk

assessment for physical and cyber attacks on critical infrastructures. In

Military Communications Conference, 2005. MILCOM 2005. IEEE, pages

1961–1969. IEEE, 2005.

Bibliography 83

[FG97] Riccardo Focardi and Roberto Gorrieri. The compositional security checker:

A tool for the verification of information flow security properties. Software

Engineering, IEEE Transactions on, 23(9):550–571, 1997.

[Fra08] Australian Flexible Learning Framework. Commonwealth of australia, 2008.

[Grö08] Gerhard Gröger. Opengis city geography markup language (citygml) encod-

ing standard, 2008.

[IKS04] Magdy Ibrahim, Robert Krawczyk, and George Schipporeit. Two approaches

to bim: a comparative study. In eCAADe Conference, volume 22, pages 610–

616, 2004.

[JGG10] Ricardo Jardim-Goncalves and António Grilo. Building information model-

ing and interoperability. Automation in Construction, 19(4):387, 2010.

[JHMR14] Erika Johansson, Darek Haftor, Bengt Magnusson, and Jan Rosvall. On

building information modeling: an explorative study. 2014.

[Khe04] Lachmi Khemlani. The ifc building model: A look under the hood. AECbytes

Feature, pages 1–10, 2004.

[KI15] Ebrahim P Karan and Javier Irizarry. Extending bim interoperability to pre-

construction operations using geospatial analyses and semantic web services.

Automation in Construction, 53:1–12, 2015.

[KK13] Jin-Hong Kim and Seung-Cheon Kim. Toward hybrid model for architecture-

oriented semantic schema of self-adaptive system. In Grid and Pervasive

Computing, pages 832–837. Springer, 2013.

[Lee08] Edward A Lee. Cyber physical systems: Design challenges. In Object Ori-

ented Real-Time Distributed Computing (ISORC), 2008 11th IEEE Interna-

tional Symposium on, pages 363–369. IEEE, 2008.

[LK12] Mikael Laakso and AO Kiviniemi. The ifc standard: A review of history, de-

velopment, and standardization, information technology. ITcon, 17(9):134–

161, 2012.

[Lon07] Benjamin W Long. The role of formal methods in high-grade infosec evalu-

ations. Technical report, DTIC Document, 2007.

[LPG14] Henrik Linderoth, Johansson Peter, and Kaj Granath. The role of bim in

preventing design errors. In Procs 30thAnnual ARCOM Conference, 1-3

September 2014, Portsmouth, UK, Association of Researchers in Construc-

tion Management, pages 703–712, 2014.

Bibliography 84

[LWL+13] Christoph Langenhan, Markus Weber, Marcus Liwicki, Frank Petzold, and

Andreas Dengel. Graph-based retrieval of building information models

for supporting the early design stages. Advanced Engineering Informatics,

27(4):413–426, 2013.

[Mad13] Jason Madden. Security analysis of a cyber physical system: a car example.

2013.

[Mil91] Robin Milner. The polyadic pi-calculus: a tutorial. Technical report, Logic

and Algebra of Specification, 1991.

[Mil01] Robin Milner. Bigraphical reactive systems: basic theory. Technical report,

Technical Report 523, Computer Laboratory, University of Cambridge, 2001.

[Mit12] David Mitchell. 5d bim: Creating cost certainty and better buildings.

In RICS COBRA 2012-the annual RICS international research conference,

pages 1–9, 2012.

[MM13] André Monteiro and João Poças Martins. A survey on modeling guidelines

for quantity takeoff-oriented bim-based design. Automation in Construction,

35:238–253, 2013.

[NAD90] E Neufert and BSP Architects’ Data. Professional books, 1990.

[NHN03] Flemming Nielson, Rena Rydhof Hansen, and Hanne Riis Nielson. Ab-

stract interpretation of mobile ambients. Science of Computer Program-

ming, 47(23):145 – 175, 2003. <ce:title>Special Issue on Static Analysis

(SAS’99)</ce:title>.

[NNG98] Ernst Neufert, Peter Neufert, and Stanisław Gawroński. Podrecznik projek-

towania architektoniczno-budowlanego. Arkady, 1998.

[PGM+14] Liliana Pasquale, Carlo Ghezzi, Claudio Menghi, Christos Tsigkanos, and

Bashar Nuseibeh. Topology aware adaptive security. In Proceedings of the

9th International Symposium on Software Engineering for Adaptive and Self-

Managing Systems, SEAMS 2014, pages 43–48, New York, NY, USA, 2014.

ACM.

[PKS12] Eloi Pereira, Christoph Kirsch, and Raja Sengupta. Biagents–a bigraphical

agent model for structure-aware computation. Cyber-Physical Cloud Com-

puting Working Papers, CPCC Berkeley, 2012.

[PP01] William M Pena and Steven A Parshall. Problem seeking: an architectural

programming primer. John Wiley & Sons, 2001.

Bibliography 85

[PPR04] Carla Piazza, Enrico Pivato, and Sabina Rossi. Cops–checker of persistent

security. In Tools and Algorithms for the Construction and Analysis of Sys-

tems, pages 144–152. Springer, 2004.

[PTTW14] Stuart Porter, Terence Tan, Tele Tan, and Geoff West. Breaking into bim:

Performing static and dynamic security analysis with the aid of bim. Au-

tomation in Construction, 40:84–95, 2014.

[RBWC11] Yacine Rezgui, Stefan Boddy, Matthew Wetherill, and Grahame Cooper.

Past, present and future of information and knowledge sharing in the

construction industry: Towards semantic service-based e-construction?

Computer-Aided Design, 43(5):502–515, 2011.

[RGK90] Jane Radatz, Anne Geraci, and Freny Katki. Ieee standard glossary of

software engineering terminology. IEEE Std, 610121990(121990):3, 1990.

[SDE09] Ruth Sengonzi, Peter Demian, and Stephen Emmitt. Optimizing healthcare

facility value through better briefing and optioneering. 2009.

[SPO+12] Mazeiar Salehie, Liliana Pasquale, Inah Omoronyia, Raian Ali, and Bashar

Nuseibeh. Requirements-driven adaptive security: Protecting variable assets

at runtime. In Requirements Engineering Conference (RE), 2012 20th IEEE

International, pages 111–120. IEEE, 2012.

[SRD+12] Nimalaprakasan Skandhakumar, Jason Reid, Ed Dawson, Robin Dro-

gemuller, and Farzad Salim. An authorization framework using building

information models. The Computer Journal, page bxs098, 2012.

[Suc09] Bilal Succar. Building information modelling framework: A research and

delivery foundation for industry stakeholders. Automation in construction,

18(3):357–375, 2009.

[Szu05] J Szuba. Graphs and Graph Transformations in Design in Engineering. PhD

thesis, PhD thesis, Darmstadt University of Technology, 2005.

[TPM+] C. Tsigkanos, L. Pasquale, C. Menghi, C. Ghezzi, and B. Nuseibeh. On the

interplay between cyber and physical spaces for adaptive security. unpub-

lished ... yet!

[TPM+14] C. Tsigkanos, L. Pasquale, C. Menghi, C. Ghezzi, and B. Nuseibeh. Engineer-

ing topology aware adaptive security: Preventing requirements violations at

runtime. In Requirements Engineering Conference (RE), 2014 IEEE 22nd

International, pages 203–212, Aug 2014.

Bibliography 86

[Tsi15] Pasquale L Ghezzi C Nuseibeh B Tsigkanos, C. Ariadne: Topology aware

adaptive security for cyber-physical systems, 2015.

[TWW05] Tao-chiu Kenny Tse, Kamdin Andy Wong, and KF Wong. The utilisation

of building information models in nd modelling: a study of data interfacing

and adoption barriers, 2005.

[Ver96] Joris SM Vergeest. Product data exchange: By m susan bloor and j owen

ucl press limited, london, uk (1995)£ 35, 262 pp, isbn 1-85728-279-5, 1996.

[YM12] Eric Yuan and Sam Malek. A taxonomy and survey of self-protecting soft-

ware systems. In Proceedings of the 7th International Symposium on Software

Engineering for Adaptive and Self-Managing Systems, pages 109–118. IEEE

Press, 2012.

[ZP99] M Kiumarse Zamanian and Jon H Pittman. A software industry perspective

on aec information models for distributed collaboration. Automation in

Construction, 8(3):237–248, 1999.

Towards a Development Environment for Secure CyberPhysical … · 2015-07-09 · Politecnico di...

Documents

Transcript of Towards a Development Environment for Secure CyberPhysical … · 2015-07-09 · Politecnico di...