towards a development environment for secure cyberphysical … · 2015-07-09 · politecnico di...
TRANSCRIPT
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 in- dustry 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
Spatial data models 14
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 rep- resent real life building components. For example, a wall object is an
object that understands the proper- ties 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
Spatial data models 15
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
Spatial data models 16
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]
Spatial data models 17
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
Spatial data models 18
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
Spatial data models 19
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
Spatial data models 20
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].
Spatial data models 21
#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.
Spatial data models 22
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.
Spatial data models 23
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.
Spatial data models 24
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)
Representing Spaces 27
Figure 4.2: Example of Graph to represent Hotel
Representing Spaces 28
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
Representing Spaces 29
Figure 4.3: Graphical representation of the Bigraph depicted in Listing 4.1
Figure 4.4: Place Graph underlying to 4.3
Representing Spaces 30
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].
Representing Spaces 31
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
Representing Spaces 32
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)IfcBuildingElement
(ABS)IfcElement
(ABS)IfcFeatureElement
Subtraction
IfcOpeningElement
IfcRelVoidsElement
(IfcRelVoidsElement.RelatedOpeningElement)(INV) VoidsElements
(IfcRelVoidsElement.RelatedBuildingElement)(INV) BoundedBy S[0:?]
IfcOpeningElement
IfcDoor
(ABS)IfcElement
IfcRelFillsElement
(ABS)IfcBuildingElement
(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/
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
Requirement Analysis 46
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
Requirement Analysis 47
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
Requirement Analysis 48
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
Requirement Analysis 49
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
Requirement Analysis 50
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
Requirement Analysis 51
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
Requirement Analysis 52
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.
Requirement Analysis 53
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
Requirement Analysis 54
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
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.
Software Architecture 57
• 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
Software Architecture 58
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.
Software Architecture 59
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
Software Architecture 60
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
Software Architecture 61
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.
Software Architecture 62
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
Software Architecture 63
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.
Software Architecture 64
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
Software Architecture 65
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.
Software Architecture 66
State {
Agents and Assets : ResourceList ,
Digital Connections : ConnectionList ,
}
[]
ResourceList Resource ,
[ Resource ]
[]
ConnectionList Connection ,
[ Connection ]
Connection graffa
label: String ,
source: String ,
targets: ListOfResourceID
}
Software Architecture 67
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",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "printer -0",
"type": "PRINTER",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "mallory",
"type": "ACTOR",
"roomId": "Corridor",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "pc -0",
"type": "PC",
"roomId": "Server Room",
"additionalAttributes": [],
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
"connectable": "true",
"contains": []
},
{
"id": "pc -1",
"type": "PC",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "bob",
"type": "ACTOR",
"roomId": "Corridor",
"additionalAttributes": [],
"connectable": "true",
"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
Agents and Assets : [
{
"id": "bob",
"type": "ACTOR",
"roomId": "Wifi Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "printer -0",
"type": "PRINTER",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "eve",
"type": "ACTOR",
"roomId": "Corridor",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "pc -2",
"type": "PC",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "mallory",
A Demonstration 72
"type": "ACTOR",
"roomId": "Corridor",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "pc -0",
"type": "PC",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "pc -1",
"type": "PC",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"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.
Agents and Assets : [
{
"id": "bob",
"type": "ACTOR",
"roomId": "Wifi Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "pc -1",
"type": "PC",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "printer -0",
"type": "PRINTER",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "eve",
"type": "ACTOR",
"roomId": "Corridor",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "pc -0",
"type": "PC",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"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",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "mallory",
"type": "ACTOR",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"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
Agents and Assets : [
{
"id": "bob",
"type": "ACTOR",
"roomId": "Wifi Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "pc -1",
"type": "PC",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "printer -0",
"type": "PRINTER",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "eve",
"type": "ACTOR",
"roomId": "Corridor",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "pc -0",
"type": "PC",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
"id": "pc -2",
"type": "PC",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"contains": []
},
{
A Demonstration 75
"id": "mallory",
"type": "ACTOR",
"roomId": "Server Room",
"additionalAttributes": [],
"connectable": "true",
"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.